Download to read offline
Uploaded byLucas Falk Beier
Blue green deployment
The document outlines the concept and implementation of blue-green deployment within a DevOps context, covering its benefits, costs, and necessary precautions. It emphasizes the importance of minimizing downtime during software production releases and highlights strategies for rapid rollbacks, especially in scenarios involving backward incompatible changes and database migrations. The document also presents a live demo and warns about potential pitfalls related to shared infrastructures and long-running transactions.
More Related Content
![[JAZUG Tohoku Azure DevOps] Azure DevOps](https://cdn.slidesharecdn.com/ss_thumbnails/20181130jazugsendaiazuredevops-181201031328-thumbnail.jpg?width=640&height=640&fit=bounds)
Blue green deployment
- 1. Blue-green deployment In practice devopsJourney@LATAM
- 2. Agenda ❏¿Que es Blue-greendeployment? ❏¿Cual son su beneficios y custos? ❏¿Qué cuidados tenemos que tomar? ❏Blue-green en practica
- 3. Cómo podremos ponersoftware en producción y minimizar el downtime? Cómo podremos hacer rollback rapidamente?
- 4.
- 5.
- 6.
- 7. Sounds good! But isthere something we might need to watch out?
- 8. Things to watchout ❏Infrastructure ❏Shared underlying infrastructures (VMs, Docker) ❏Long running transactions on current environment ❏Backward incompatible changes ❏Database migrations ❏ Changes on APIs response
- 9. Dealing with backwardincompatibility ❏Expand and contract strategy ❏Works for changes on: ❏ API contracts breaks ❏ DB Changes ❏ Dependent systems (Sabre, coordinated microservices changes)
- 10. Changing DB schema ❏Separatedeploy: ❏ Schema changes ❏ Application upgrades ❏DB refactoring + current application version = rollback point
- 11. Expand and contractapplied on DB changes ❏Apply a database refactoring ❏ expand DB ❏Deploy the database refactoring ❏ expand app ❏Remove the support to older schema ❏ contract db and app
- 12. Live demo When thethings usually don't work as expected...
- 13.
Editor's Notes
- #5 Blue-green is a technique to deploy your application in a predictable manner and one of the goals is to reduce the downtime associated with the release. Simply you have two identical environments. In our case, the green environment has the current version of our application. When you ran all your integration pipeline and tests, you can deploy the new version of application to blue environment and run some smoke tests and any other tests you might find worth to do so. Api Management as Load Balancer for Services
- #6 Blue-green is a technique to deploy your application in a predictable manner and one of the goals is to reduce the downtime associated with the release. Simply you have two identical environments. In our case, the green environment has the current version of our application. When you ran all your integration pipeline and tests, you can deploy the new version of application to blue environment and run some smoke tests and any other tests you might find worth to do so. Api Management as Load Balancer for Services
- #7 Once you are confident that the version the new version is stable, you simply switch the load balancer/router to the blue environment. Now you can monitor for any issues in the new release. If everything looks good, you can shutdown the green env and use it to stage any new releases. If you find any issues, you can simply point the loadbalancer back to green. This way you the blue and green envs are cycling between live (current), previous (for rollback) and next version.
- #9 You have to have an infrastructure to deal with this When you try blue-green in a non-isolated infrastructure, you run the risk of destroying BOTH blue and green envs When you switch over to blue, you have to gracefully handle those outstanding transactions as well as the new ones. Database migrations can get really tricky and would have to be migrated/rolledback alongside the app deployments.
- #10 Databases can often be a challenge, specially if you are changing the schema. The tip is to separate the deployment of schemas changes from application upgrades First apply a database refactoring to change the schema to support the old and new version of the application, then deploy the DB refactoring After you make sure everything works fine with the current version of application (to have a rollback point), deploy the new version of the application Once you make sure things are working as expected, remove the support to the older version.
- #11 Databases can often be a challenge, specially if you are changing the schema. The tip is to separate the deployment of schemas changes from application upgrades First apply a database refactoring to change the schema to support the old and new version of the application, then deploy the DB refactoring After you make sure everything works fine with the current version of application (to have a rollback point), deploy the new version of the application Once you make sure things are working as expected, remove the support to the older version.
- #12 Databases can often be a challenge, specially if you are changing the schema. The tip is to separate the deployment of schemas changes from application upgrades First apply a database refactoring to change the schema to support the old and new version of the application, then deploy the DB refactoring After you make sure everything works fine with the current version of application (to have a rollback point), deploy the new version of the application Once you make sure things are working as expected, remove the support to the older version.