Once we have the our code ready to be deployed, there are multiple ways that we could proceed with the deployment. This post looks into some of the most common deployment strategies.
Big Bang Deployment
This is one of the earliest methods of deployments, where we deploy all our changes at once, causing some downtime while we transition from the old system to the new. While usually short, the downtime depends on the scale of the system. In case we need to rollback if things go down as planned, we’ll be having additional downtime while the system rolls back to the previous version, so testing and preparation are key. In some cases, Big Bang might be the only choice, like when an intricate database upgrade is involved. By the way, the name refers to the physical theory1 that describes how the universe expanded from an initial state of high density and temperature.
Rolling Deployment
Rolling deployment, as the name suggests, involves incrementally rolling out the changes to different parts of the system in a progressive manner. For example, imagine we have 6 servers running the same service. With a rolling deployment, we’ll take down the first server and replace it with the new version. Once the “new first server” is up and running, we’ll move on with the other servers—gradually. This method usually prevents downtime, which is an advantage. However, it’s slower, and does not allow targeted rollouts—where we control which specific user base will see the new version based on criteria like location, device type, etc.
Blue-green Deployment
With Blue-green deployments, we maintain two “identical” production environments. Once (blue) is active and is serving live traffic, while the other (green) is used for deployments and testing. Let’s say we have a version ready for deployment. We deploy it to the green environment, while the blue environment keeps serving all users. Then we proceed with necessary tests in the green environment, fixing any bugs that might be found. Then once the green environment is ready, we switch the load balancer from the blue environment to green. In case any issues are following the migration, we can simply re-switch the load balancer. Once the migration is complete without issues, the environment identities are switched as well, with the environment serving live traffic becoming blue (was green), and likewise. This strategy also does not allow targeted rollouts, and will incur higher budget/management/maintenance resources. However, it minimizes the deployment risk by a large margin, with a smooth user experience and reliable rollbacks.
Canary Deployment
Named after the use of canaries to warn miners of toxic gases2, this is a progressive rollout of an application that splits traffic between an already-deployed version and a new version, rolling it out to a subset of users before rolling out fully. In other words, this process entails launching a new version of the application while keeping the old version active. Initially, the old version serves the majority of users, while a small group of test users access the new version. If the new deployment proves successful, it is gradually extended to more users. This is usually used in combination with rolling deployment strategy to have an ideal synthesis.
Please note that there are many strategies and combinations that could be used when rolling out changes, we only discussed a few common strategies. Selecting the appropriate strategy for our requirements can minimize downtime, facilitate testing, and enhance the customer feedback loop, which allows the team to develop a better product over time.
This video3 will help your understanding of different deployment strategies since the inclusion of visual components.