Rollback strategies with Octopus Deploy

Показать описание

Often, we want to solve the most complex DevOps challenge first: automatically rolling back when we discover an issue. But is that feasible or recommended for your application?

Rolling back would be simple if it weren't for that pesky database. Without the database, a rollback is as simple as changing a load balancer configuration or redeploying the previous version. Applications need to store data somewhere. Changing an existing application from a relational database to a NoSQL database is costly and time-consuming.

Because of the database, rolling forward is faster and less risky, especially if a deployment pushes dozens or hundreds of changes. But rollbacks can be an effective recovery strategy.

In this webinar, Bob Walker (Field CTO, Octopus Deploy) discusses techniques to remove databases from rollbacks. Specifically, he outlines 4 strategies you can apply in your application today:

- Skip database-specific steps in your deployment process during a rollback.
- Decouple database changes and apply the expand / contract pattern.
- Adopt a blue/green or "staging" deployment pattern to test changes in production before users can access them.
- Use blue/green or "staging" deployment patterns to promote a roll-forward mentality.