Rework "serverless rollback" support

This is a Feature Proposal

Description

A while back we’ve introduce rollback support for serverless deployments with the help of the serverless deploy list and serverless rollback --timestamp commands.

This supports enables a way to take a look at all the deployment artifacts which are stored in the deployment bucket (with the help of serverless deploy list) and then rollback to a specific deployment based on the timestamp of the deployment (with the help of the serverless rollback --timestamp command).

While this is a good starting point it is worthwhile to re-think the whole behavior and functionality and add support for more feature rich deployment rollbacks.

This issue discusses potential improvements and current issues we should fix in an upcoming update.

Current issues:

• It’s currently not visible which version of the service is currently deployed when running serverless deploy list
• Rollbacks can’t be automated due to hard to parse CLI output (see here for more info).
• Rollback doesn’t re-upload the files which will break the “Skip if files not changed” functionality (because it always compares to the most recent deployment)
• Picking a version to rollback to based on the timestamp is not a great DX

Feature wishlist:

• Add support to rollback to previous versions with the help of a number options (such as serverless rollback -n 4 --> Rollback 4 versions in time)
• Parseable output? (discussed and implemented in https://github.com/serverless/serverless/issues/3089)
• …

/cc @brianneisler @eahefnawy

[jscattergood]

We implemented the scripted approach to perform an automatic rollback using Jenkins, but found that serverless deploy list also includes the broken deployment and there isn’t a command to remove the broken deployment. So without a reference to the timestamp that’s actually deployed, we can’t reliably determine which timestamp to rollback to if there is another failed deployment.

It may be simple enough keep a file containing the timestamp of each deployment and the bucket that was deployed. A new command serverless deploy history would retrieve this info. The last entry would be the currently deployed timestamp.

Any thoughts?

[goncaloneves]

deploy list and rollback probably are the most important Serverless commands after deploy.

My idea is, adding a Serverless meta data information file to S3 deployments that could provide more info in the deploy list command such as:

• Serverless version
• Provider
• Region
• Stage
• Function versions
• Custom key/value (set in serverless.yml)
• Copy of the entire serverless.yml (?)

At deploy time this file could get custom data from serverless.yml if the developer wants to associate specific tags and key/value to a specific deployment.