Feature request:Rollback command

[bokuweb]

Note: If your feature-request is regarding the AWS Amplify Console service, please log it in the official AWS Amplify Console forum

Is your feature request related to a problem? Please describe. No. It's enhancement.

Describe the solution you'd like I would like to rollback published version like following

$ amplify env prod rollback
$ select date or version?
  > 2019-05-11
     2019-05-10
     2019-05-09

Describe alternatives you've considered Is it possible with current architecture??

Additional context Add any other context or screenshots about the feature request here.

[yuth]

This might need some bit of work in the platform to support.

I have marked this as a feature request and I will get the product team to review this.

You could achieve this by using your version control system like git. After every push you could create an git tag and then checkout the tag if you want to restore to this point

git tag -a push-2019-05-11 -m "pushed on 2019-05-11"

[xoadrian]

@yuth I think @bokuweb is interested in something else and so do I. It is not about code versioning, it is about deployment.

Let's say I deployed to production, and customers are starting to complain about some issues with the new release, we would like to be able to revert whatever was in the cloud previously before last deployment. Which means I should be able to tell amplify to rollback to some previous stacks.

I checked the S3 bucket for deplyment, it seems there is already versioning for stacks + resolvers. So I think this should be possible to just point to a specific versioning and deploy to the cloud previous stacks.

Currently the only possibility is:

1. destroy environment
2. rollback git to a previous state (like you suggested above)
3. re-create the environment, cause we need specifically same environment - otherwise it makes no sense
4. re-deploy.

And all this is manual work and time consuming, it would be much easier to just redeploy already existing stacks from S3.

Plus this can also be improved for hosting bucket, to have versioning also there, so that it just points to already previously deployed UI. Currently hosting bucket is just uploading everything above, there is no way to specify some previous uploaded version of the file.

[aukaurea]

@yuth, @kaustavghosh06, @UnleashedMind I also support the below features (from @xoadrian) :

• destroy the environment
• rollback git to a previous state (like you suggested above)
• re-create the environment, cause we need specifically the same environment - otherwise, it makes no sense
• re-deploy.

[patrykkrz]

@aukaurea Good idea, but what about this example:

• before add "new category" on prod env exist DynamoDB with clients data
• added "new category" to prod env
• we need revert "new category"

After destroy the environment, we are losing dynamoDB with customer data.

Is there any way to do this? The only way I know is to use "amplify remove" manually, but you have to remember and know about it. I think that the git should do, not the human.

At the very beginning I tried to go back to the specified commit and "amplify push". I expected that if I go back to a specific commit via git, the "amplify status" would show the "Operation" in the "Storage category" as "removed", but it doesn't work that way.

[ChenLi0830]

Any update on this? Not being able to roll back is a major issue to use amplify in a production environment

[ChenLi0830]

@yuth I tried your idea, but I expect after checkout the old tag, amplify push will restore the aws to that corresponding state for its infrastructures that corresponds to the old tag's commit. However, it didn't work for me.

[nathanagez]

Any updates @yuth ?

[undefobj]

@edwardfoyle @swaminator tagging as FYI

[mswezey23]

Any updates? I would love to see a slick Github <> Amplify rollback mechanism that's natively supported.

[giancarlosisasi]

Hi there! is there any updates about this 😢

Now that we have gen 2, should we create an issue in that repo instead?