Hands-On Microservices with Kubernetes

Dealing with a rollback after a schema, API, or payload change

The deployment strategy you choose often depends on the nature of the change the new version introduces. For example, if your change involved a breaking database schema change, such as splitting table A into two tables, B and C, then you can't simply deploy the new version that reads to/writes from B and C. The database needs to be migrated first. However, if you run into problems and want to roll back to the previous version, then you'll have the same problem in the reverse direction. Your old version will try and read from/write to table A, which doesn't exist anymore. The same issue can happen if you change the format of a configuration file or payload on some network protocol. ...