- Automating your deployment helps in reducing the frictions and delays that crop up in between getting the software "done" and getting it to realise its value.
- Being done with your code and your code benefiting people are two different things
- Your code might be done for you but it might take time for the testing, deployment, and actual end user testing.
- One of the major challenges over deployment is the cut-over.
- When deployment is taking place, the current instance goes down while the new instance is compiled and prepared to take the position
- This process of taking current version down from the production causes downtime for the service
- The Blue Green deployment approach does this by ensuring you have two production environments, as identical as possible.
- At any point of time, blue env is live.
- As you prepare a new release to your software, you do your final stage of testing in the green environment.
- Once software is working in green environment, you switch the router so that all incoming requests go to the green environment, the blue one now sits idle.
- Blue-Green deployment gives a rapid way to rollback
- If anything goes wrong you are one router redirection away to your previous (blue) deployment.
- The two environments need to be different but as identical as possible
- Maybe different pieces of hardware
- Different virtual machines on the same (or diff) hardware
- A single Operating Environment partitioned into separate zones with separate IP addresses for the two slices.
Which one is live which one is hot-standby?¶
- Both Green and blue environments are regularly cycling between live, previous version (for rollback) and staging the next version.
- This ability to roll back to previous version allows you to test disaster recovery on every release
- Fundamental idea is to have two easily switchable environments to switch between
How to Manage Database Changes?¶
- Separate the deployment of schema changes from application upgrades
- perhaps write a migration file for this ( #doubt)
- First, apply a database refactoring to change the schema to support both the new and old version of the application.
- Deploy the above DB configuration, check if everything is working fine. This is your rollback point.
- Now, deploy the new version of the application.
- When the upgrade is completed (deploy and prod-test), remove the database support for the old version.