Rolling deployment, also known as incremental deployment, is a software release strategy where the new version of an application is gradually deployed across multiple instances while minimizing downtime, risks, and impact on end-users. This is done by incrementally replacing instances running the old version with instances running the new version, ensuring a seamless transition from one version to another without affecting the entire system or its users.
Rolling deployments are typically employed in environments with multiple instances or nodes, such as distributed or horizontally-scaled systems. This method allows for a smoother transition, better error isolation, and easier rollback in case of problems.
Here are some scenarios where rolling deployment could be beneficial:
1. Ensuring minimal downtime: When updating an application, completely stopping the service might not be feasible or desirable because it would create a service interruption for users. With rolling deployments, only a subset of instances is updated at a time, while the remaining instances continue to handle requests.
2. Mitigating risks: Rolling deployment helps reduce risk associated with updates by applying changes to a smaller subset of instances. If any issues arise during deployment, they would have a lower impact on the entire system and can be easily fixed or rolled back, thus reducing the blast radius.
3. Continuous delivery: Organizations that adopt continuous delivery and continuous integration (CI/CD) methodologies often use rolling deployments to push updates more frequently, as it lessens the potential impact on users.
4. Load balancing: In a large-scale environment with high traffic, it’s important to maintain the capacity to handle incoming requests. Rolling deployments can ensure that there’s always enough capacity available, as only a portion of instances is upgraded at any one time.
5. Easier rollbacks: If a problem occurs during the deployment, it’s simpler to rollback to the previous version with rolling deployments because only a small portion of instances would need to be reverted.
Here’s an example illustrating the stages of rolling deployment in a system with six instances:
Stage 1: [v1] [v1] [v1] [v1] [v1] [v1]
Stage 2: [v2] [v1] [v1] [v1] [v1] [v1]
Stage 3: [v2] [v2] [v1] [v1] [v1] [v1]
Stage 4: [v2] [v2] [v2] [v1] [v1] [v1]
Stage 5: [v2] [v2] [v2] [v2] [v1] [v1]
Stage 6: [v2] [v2] [v2] [v2] [v2] [v1]
Stage 7: [v2] [v2] [v2] [v2] [v2] [v2]Each stage involves deploying the new version (v2) to one instance at a time, making sure that all instances are updated and there’s no downtime throughout the process.