What Is Rolling deployment in DevOps?
On This Page
Quick Definition
Rolling deployment updates an application by swapping out old parts for new ones a little at a time, without taking the whole system offline. Instead of shutting everything down at once, you update a few servers, test them, then move on to the next group. This keeps the service running throughout the entire update process.
Commonly Confused With
Blue-green deployment uses two separate environments (blue and green) and switches all traffic from one to the other at once. This allows instant rollback by switching traffic back. Rolling deployment updates instances in place, one batch at a time, without a second environment. Rolling deployment is cheaper but has slower rollback. Blue-green deployment is faster to rollback but doubles infrastructure cost.
Blue-green is like having two identical stadiums and moving the crowd from one to the other when you need to renovate. Rolling is like repainting sections of a single stadium while the game continues in other sections.
Canary deployment routes a small percentage of traffic to a new version to test it before gradually increasing that percentage. This allows careful testing with real traffic. Rolling deployment replaces all instances in batches, with no small initial testing subset specifically for observation. Canary is better for validating changes on real users without full commitment. Rolling is simpler and faster for a full rollout.
Canary is like offering a new menu item at just one restaurant in a chain to see if customers like it before rolling it out everywhere. Rolling is like updating the menu at each restaurant one by one.
A/B testing is not a deployment strategy but a method to compare two versions of a feature to measure user behavior or performance. It often uses routing or flags to split traffic. Rolling deployment is solely about updating all instances to a new version with no comparison or measurement of user behavior. A/B testing is about experimentation; rolling deployment is about delivery.
A/B testing: Show half the users a red button and half a blue button to see which gets more clicks. Rolling deployment: Replace all red buttons with blue buttons over time.
Must Know for Exams
Rolling deployment is a common topic in several IT certification exams, especially those focusing on DevOps, cloud architecture, and software delivery. For AWS Certified Solutions Architect (SAA-C03), rolling deployment appears in the context of AWS Elastic Beanstalk, Amazon ECS, and Auto Scaling groups. You may be asked to select the best deployment strategy for a scenario that requires zero downtime and minimal cost. Rolling deployment is often compared with blue-green and canary deployments. Exam questions may test your understanding of when to use each strategy based on factors like cost, complexity, rollback speed, and risk tolerance.
For the AWS Certified DevOps Engineer (DOP-C02) exam, rolling deployment is more deeply tested. You may need to implement rolling updates in AWS CloudFormation stacks, control update policies, and handle deployment failures using rollback triggers. Questions might ask about the difference between “rolling update” and “replace” policies, or how to configure a rolling update to maintain a minimum number of healthy instances. Hands-on knowledge of CodeDeploy’s deployment configuration, such as “AllAtOnce” vs. “OneAtATime” vs. “HalfAtATime” rollout options, is also relevant.
In the Microsoft Azure ecosystem, the AZ-104 and AZ-400 exams cover rolling deployment as part of Azure App Service deployment slots and Azure Kubernetes Service upgrades. You might be asked about slot swapping vs. rolling update, or how to configure rolling updates in an Azure VMSS. The concept also appears in the Google Cloud Professional DevOps Engineer exam, where you must design a deployment pipeline that uses rolling updates with health checks and rollout policies.
For the Kubernetes certification (CKA and CKAD), rolling deployment is central. The exam requires you to create and manage Deployments with rolling update strategies, update container images, verify rollout status, and roll back failed updates. Questions often involve writing YAML manifests with rollingUpdate settings, and troubleshooting deployments that are stuck due to failed readiness probes. The Certified Kubernetes Application Developer (CKAD) exam also tests your ability to update applications with zero downtime using rolling updates.
In general IT certifications like CompTIA Cloud+ or CompTIA DevOps+, rolling deployment may appear as part of change management or software deployment lifecycle. You may need to identify the benefits, limitations, and appropriate use cases. The key exam takeaway is that rolling deployment provides zero-downtime updates with low infrastructure cost, but requires backward compatibility and robust health checks. Exams often test the trade-offs between deployment strategies, so be ready to compare rolling, blue-green, and canary deployments in terms of complexity, cost, rollback speed, and risk.
Simple Meaning
Think of a rolling deployment like replacing the light bulbs in a large office building. You don’t turn off the electricity for the whole building and change every bulb at once. That would leave everyone in the dark. Instead, you go floor by floor, room by room. You take a few bulbs out, screw in new ones, and by the time you finish one area, people there can get back to work. The rest of the building keeps functioning normally because its bulbs are still working.
In software, a rolling deployment works the same way. Imagine you run a website that uses ten servers to handle all visitors. Instead of taking all ten offline to install an update, you start with one server. You redirect traffic away from that server, update its software, test it, and then send traffic back to it. Then you move to the next server, and the next, until all ten are running the new version. At no point do all servers go down at once. Visitors keep seeing a working site, and they typically don’t notice any interruption.
The key idea is gradual replacement. This approach avoids the “big bang” of a blue-green deployment, where you switch from one entire environment to another, and instead updates happen in a controlled, measured way. It is especially useful for systems that must be available all the time, like online stores or banking apps. If something goes wrong with the new version, you can stop the roll and roll back only the servers that have changed, leaving the rest on the old stable version. This minimizes risk and keeps users happy even during updates.
Full Technical Definition
Rolling deployment is a software release strategy that updates a running application by incrementally replacing old instances with new ones across a fleet of servers, containers, or nodes, without taking the entire service offline. It is a core practice in continuous delivery and DevOps, often implemented by orchestration tools such as Kubernetes, AWS Elastic Beanstalk, Azure DevOps, and Spinnaker. The deployment process typically works within a load-balanced environment, where an upstream load balancer distributes traffic across multiple application instances.
In a typical rolling deployment, the orchestrator first identifies a subset of instances to update, often called a “batch” or “wave.” The size of this batch is defined by a configuration parameter such as “rollingUpdate.maxSurge” and “rollingUpdate.maxUnavailable” in Kubernetes. The orchestrator terminates or drains traffic from those instances, updates them with the new artifact (for example, a Docker container image or a compiled binary), and verifies the instances are healthy using a readiness probe or health check. Once the first batch is healthy, traffic is routed back to them. The orchestrator then proceeds to the next batch, repeating the process until all instances run the new version.
This approach requires that the application supports backward compatibility, particularly for state management and data schemas. During the update, both old and new versions coexist for some time. New code must be able to read and write data in a format that old code can handle, and vice versa. This is often enforced by database migration strategies that use additive schema changes (e.g., adding columns rather than renaming or removing them). For session state, the deployment may use sticky sessions or external session stores like Redis to prevent users from losing their session during the transition.
Rolling deployments are distinct from blue-green deployments, in which you maintain two complete environments and switch traffic all at once, and from canary deployments, which route a small percentage of traffic to a new version for testing before expanding. Rolling deployments are simpler to implement but require careful monitoring of health checks. If a batch fails its health check, the deployment is typically paused or rolled back automatically. Tools like Kubernetes use a rolling update strategy with a specified revision history limit to enable easy rollback. Rollback is accomplished by reversing the sequential replacement process or by redeploying the previous artifact to all instances.
Key components in a rolling deployment include: a load balancer to manage traffic distribution, health probes (HTTP, TCP, or command-based) to validate instance readiness, a configuration management system (e.g., Helm charts, Ansible, or Terraform) to define the desired state, a CI/CD pipeline to build and push the new artifact, and a monitoring stack (e.g., Prometheus, Datadog) to detect anomalies during the rollout. Execution policies such as “ramped” (linear batches) vs. “exponential” (increasing batch size) can be used to balance speed with safety.
Real-Life Example
Imagine you own a chain of coffee shops in a city. You have ten stores, and you want to introduce a new espresso machine that makes better coffee. You can’t shut down all ten stores at once because you would lose a whole day of sales, and customers would go to competitors. Instead, you pick one store to start. You close that store for a few hours, swap out the old machine for the new one, train the baristas, and then reopen it. You watch how it goes for a day. If customers love the new coffee and the machine works fine, you move to the next store. You repeat this process store by store. By the time you finish, the whole chain is upgraded without ever having a day when every store is closed.
Now, let’s map this to IT. Your coffee shops are the servers running your web application. The new espresso machine is the new version of your software. The training and testing are the health checks. If one store’s new machine breaks, you can swap the old one back quickly without affecting the other nine stores. That’s the rollback advantage. The customers (users) never experience a full outage because at least 90% of the stores are always open.
There is another nuance: during the transition, some customers might get coffee from the old machine while others get coffee from the new one. If the new coffee tastes slightly different, that inconsistency is okay as long as it’s still good. In software, this means that during a rolling deployment, different users might see different versions of the app for a short time. This is acceptable as long as the new version is backward compatible. If you had changed the size of the coffee cup (the data schema) without warning, you might cause confusion for baristas (database errors). So you need to plan for coexistence. That is exactly what a well-designed rolling deployment does: it updates gradually, monitors carefully, and rolls back instantly if needed.
Why This Term Matters
Rolling deployment matters because modern IT systems must be available continuously. Users expect services to be up 24/7, especially for critical applications like e-commerce, banking, healthcare, and social media. Taking a system offline for a deployment, even for a few minutes, can cause significant revenue loss, user frustration, or security vulnerabilities. Rolling deployment solves this by updating systems without downtime.
For DevOps teams, rolling deployment is a fundamental pattern for achieving high deployment frequency and reducing release risk. Instead of a big-bang release where many changes go live at once, rolling deployment allows a team to release small changes incrementally. If a defect is introduced, only a fraction of users are affected, and the deployment can be halted and rolled back quickly. This supports the DevOps principle of failing fast and recovering faster.
Rolling deployment also enforces good engineering practices. To succeed with rolling deployment, teams must implement robust health checks, automated testing, and database migration strategies that are backward compatible. This forces a higher standard of code quality and operational readiness. Without these practices, a rolling deployment might silently break the application for a subset of users, making detection harder.
In real-world IT operations, rolling deployment is often used for containerized applications orchestrated by Kubernetes. DevOps engineers configure rolling update strategies in deployment manifests, setting parameters like maxSurge and maxUnavailable to control the speed and impact of updates. This allows the system to autoscale during the update, ensuring that capacity remains stable. The ability to perform rolling updates is a key requirement for any production-grade system. It is also a core concept in site reliability engineering (SRE), where the goal is to balance release velocity with system reliability. Understanding rolling deployment helps IT professionals design resilient architectures and respond effectively to deployment failures.
How It Appears in Exam Questions
Exam questions about rolling deployment typically fall into three patterns: scenario-based selection, configuration analysis, and troubleshooting.
Scenario-based selection questions present a business requirement and ask you to choose the best deployment strategy. For example: “A company runs a microservices application on a Kubernetes cluster with 10 replicas. They need to deploy a new version with zero downtime and minimal cost. They also want the ability to quickly roll back if the deployment fails. Which deployment strategy should they use?” The correct answer would be rolling deployment, because it uses existing infrastructure (no extra cost for a parallel environment), provides zero downtime, and supports rollback via Kubernetes revision history. A trap option might be blue-green deployment, which offers faster rollback but requires double the infrastructure cost.
Configuration analysis questions give you a YAML snippet or a command and ask you to identify the deployment behavior. For instance, a Kubernetes Deployment manifest might show: spec: replicas: 5 strategy: type: RollingUpdate rollingUpdate: maxSurge: 25% maxUnavailable: 25%. An exam question could ask: “During the rolling update, what is the maximum number of pods that can be unavailable at any time?” The answer is 25% of 5, rounded up, meaning 1.25 is rounded down to 1 pod. Similarly, you might be asked about the effect of setting maxSurge to 0 and maxUnavailable to 1. Understanding these parameters is critical for exam success.
Troubleshooting questions often start with a scenario where a deployment has stalled or failed. For example, “A DevOps engineer performed a rolling update on an Auto Scaling group of EC2 instances using CodeDeploy. After the update, half of the instances are showing as unhealthy in the target group. What is the most likely cause?” The answer could involve a failed health check or a missing dependency in the new application version. Another variant: “A rolling update in Kubernetes is stuck at ‘Waiting for rollout to finish’ and new pods are crash looping. What is the first thing to check?” The correct step is to examine the logs of the new pod or check the readiness probe configuration.
Some questions test the order of operations. For instance, “In a rolling deployment using a load balancer, what happens first when updating an instance?” The answer is that the instance is deregistered from the load balancer, then updated, then health-checked, and then reregistered. Understanding this sequence helps in questions about traffic loss or request failures during the update.
Finally, comparison questions may ask you to list one advantage of rolling deployment over blue-green deployment. The typical answer is lower cost because no additional infrastructure is required. The disadvantage is longer rollout time and more complex rollback. Be prepared to articulate these trade-offs clearly.
Practise Rolling deployment Questions
Test your understanding with exam-style practice questions.
Example Scenario
You are an IT support specialist at an online bookstore. The company runs its website on six web servers behind a load balancer. The servers are identical and serve the same customer requests. The development team has created a new feature that allows customers to save items to a wishlist. They want to deploy this update without any downtime because the store expects a surge in traffic this weekend.
Your manager asks you to plan the deployment. You decide to use a rolling deployment strategy. Here is how you implement it:
First, you confirm that the new application code is backward compatible with the existing database. You check that any new database fields are added as optional or nullable, so old code can still read the database without errors. Then you log into the load balancer management console. You configure it to take one server out of rotation. The load balancer stops sending new requests to Server A, but existing sessions are allowed to finish (draining mode). After the current requests complete, Server A becomes idle. You then SSH into Server A, stop the web server service, copy the new application files over the old ones, update the configuration, and restart the service. You run a few manual tests on the server’s private IP to ensure the wishlist feature works. Once confirmed, you tell the load balancer to add Server A back into rotation. Traffic flows to it again.
Next, you repeat the same process for Server B, then Server C, and so on. You wait a few minutes between each server to monitor error rates and response times. By the time you finish Server F, all six servers are running the new version. The entire update took about 45 minutes, and at no point were all servers unavailable. Customers shopping during that time did not notice any interruption, though some customers who were on a session that moved from Server A to Server B might have experienced a short lag while their session was recreated on the new server (if the session was not stored externally). To avoid that, you used a shared Redis cache for sessions, so the user’s cart and login status were preserved seamlessly.
In this scenario, the rolling deployment allowed a safe, gradual release. When you updated Server B, you noticed that a configuration file was missing. You immediately stopped the deployment, fixed the file, and restarted from where you left off. Because only one server was affected at a time, the impact was small and easily reversed.
Common Mistakes
Thinking that rolling deployment guarantees zero downtime even if the application is not backward compatible.
If the new version cannot handle data written by the old version, requests during the transition period can cause errors, data corruption, or partial failures. Rolling deployment does not eliminate the need for backward compatibility.
Always test backward compatibility for data schemas and APIs before starting a rolling deployment. Use additive schema changes and versioned endpoints.
Setting maxUnavailable to 0 and expecting the deployment to proceed quickly.
Setting maxUnavailable to 0 means no instances can be taken down at once, so the deployment cannot even begin, because it requires at least one instance to be removed or updated. The deployment may hang or fail to start.
Set maxUnavailable to at least 1 (or 10-25% of the replica count) to allow the first batch to be updated. You can keep maxSurge also small to limit extra resource usage.
Confusing rolling deployment with blue-green deployment and assuming both require double infrastructure.
Blue-green deployment requires two separate environments to be maintained, which doubles infrastructure cost. Rolling deployment reuses the same environment and updates instances in place, so no extra resources are needed (unless you use maxSurge to temporarily add extra capacity).
Remember that rolling deployment works on existing instances, while blue-green uses a parallel fleet. This is a key exam distinction.
Forgetting to configure health checks or readiness probes before the rolling update.
Without health checks, the orchestration system cannot know if a newly updated instance is actually working. It may consider it healthy even if the application is broken, leading to a silent failure affecting user traffic.
Always define a readiness probe (e.g., an HTTP endpoint that returns 200) that verifies the application is fully up and able to serve requests. Configure a startup probe if the app takes time to initialize.
Assuming that rolling update always rolls forward and cannot be reversed easily.
Rolling deployments can be rolled back, but the rollback process is also gradual and may take time. If you need instant rollback, blue-green or canary with active traffic switching might be better. Some learners think rolling back is instantaneous.
Understand that rollback in a rolling deployment follows the same step-by-step process, replacing new instances with the previous version. In Kubernetes, you can use `kubectl rollout undo` but it is not immediate.
Exam Trap — Don't Get Fooled
{"trap":"A question describes a scenario where a company wants to deploy a new version of an application with zero downtime and the ability to immediately switch back to the old version if something goes wrong. The options include rolling deployment, blue-green deployment, and canary deployment. Many learners choose rolling deployment because it is the most common, but they overlook the requirement for \"immediate\" rollback.
Rolling deployment takes time to roll back because it must replace instances one by one. Blue-green deployment allows an instant traffic switch back to the old environment.","why_learners_choose_it":"Learners see the words \"zero downtime\" and immediately think of rolling deployment because it is a familiar term.
They also may not fully understand the difference in rollback speed between strategies. The trap works because rolling deployment does offer zero downtime, but the rollback is not instant.","how_to_avoid_it":"Read the requirement carefully.
If the question explicitly says \"instant rollback\" or \"immediate switch back,\" consider blue-green deployment as the better fit. If it says \"low cost\" or \"uses existing infrastructure,\" then rolling deployment is more appropriate. Always map the specific requirement to the strategy's strengths and weaknesses."
Step-by-Step Breakdown
1. Prepare the new artifact
Build the new version of the application (container image, binary, or package). Ensure it is backward compatible with existing data schemas and APIs. Push it to a central repository like Docker Hub, ECR, or a package manager.
2. Configure the orchestration platform
Define the rolling update strategy in your deployment configuration. For Kubernetes, set spec.strategy.type: RollingUpdate, and set rollingUpdate.maxSurge and rollingUpdate.maxUnavailable. For AWS CodeDeploy, choose a deployment configuration like OneAtATime or HalfAtATime.
3. Start the deployment
Trigger the CI/CD pipeline or run the update command (e.g., kubectl set image). The orchestrator begins by identifying the first batch of instances to update based on the maxUnavailable and maxSurge settings.
4. Drain traffic from the batch
The load balancer or orchestrator stops sending new requests to the instances in the batch. Existing connections may be allowed to finish (connection draining). This prevents requests from hitting an instance that is about to be updated.
5. Update instances in the batch
The orchestrator replaces the old artifact with the new one on each instance. This may involve pulling a new container image, installing a new package, or copying files. The instance is then restarted or reloaded.
6. Perform health checks
After the update, the orchestrator runs health checks (e.g., readiness probe, HTTP health endpoint) to verify the instance is ready to serve traffic. If health checks fail, the deployment may pause or mark that batch as failed.
7. Restore traffic to the batch
Once the health checks pass, the load balancer adds the instances back into rotation. Traffic flows to them again. The system continues serving requests while the orchestrator moves on to the next batch.
8. Repeat for remaining batches
The orchestrator iterates through all instances in the cluster, updating each batch sequentially until every instance runs the new version. The process continues until the desired state is reached.
9. Monitor the rollout
During and after the deployment, monitor application metrics (error rates, latency, throughput) to ensure the new version is working as expected. If issues are detected, initiate a rollback by reversing the process.
10. Rollback if necessary
If the deployment fails or degrades performance, use the same incremental process to replace new instances with the previous stable version. Kubernetes supports `kubectl rollout undo` to revert to the last revision.
Practical Mini-Lesson
Rolling deployment is one of the most practical release strategies for DevOps teams. In a real-world context, you will use an orchestrator like Kubernetes, AWS CodeDeploy, or Azure DevOps to manage the rollout. The key configuration parameters are batch size, health check intervals, and rollout speed. Understanding these can mean the difference between a smooth release and a production incident.
Let’s look at a typical Kubernetes rolling update. You have a Deployment with 10 replicas. You set rollingUpdate.maxSurge to 2 and rollingUpdate.maxUnavailable to 1. This means the deployment can create up to 2 extra pods above the desired 10 (so as many as 12 total), and at most 1 pod can be unavailable during the update. The orchestrator first creates 2 new pods with the new image alongside the 10 old pods. Once the new pods are healthy, it terminates 2 old pods. It repeats this process until only new pods remain. The maximum surge allows the update to proceed faster, but it requires enough cluster capacity to run extra pods. If your cluster is resource-constrained, you might set maxSurge to 0 and rely on taking down old pods first.
For AWS users, CodeDeploy offers a similar concept with deployment configurations. You can choose “OneAtATime” (like rolling batch size of 1), “HalfAtATime,” or “AllAtOnce.” The deployment group typically targets an Auto Scaling group. CodeDeploy deregisters each instance from the load balancer, installs the new revision, runs validation scripts, and then registers it back. If a validation script fails, the deployment stops and may automatically roll back. You can also configure an alarm to trigger automatic rollback if the error rate spikes.
What can go wrong? The most common issues are: the new version fails health checks repeatedly, causing the rollout to stall; the database migration is not backward compatible, causing errors when old and new versions coexist; and insufficient capacity to handle the surge of extra pods during the update. To mitigate these, always test the new version in a staging environment with a similar load, implement gradual rollout with small batch sizes for critical systems, and use feature flags to decouple deployment from release. Also, set a deployment timeout so that if the process hangs, it is automatically marked as failed and triggers a rollback.
Professionals should also understand the difference between rolling update and rolling restart. A rolling restart simply terminates and restarts all instances with the same artifact, while a rolling update replaces the artifact. Tooling like kubectl rollout restart is useful for picking up new configuration or secrets without changing the application version.
Finally, remember that rolling deployment is not suitable for every scenario. If you need to change database schemas in a breaking way, or if the application cannot handle two versions running simultaneously, consider blue-green deployment with a controlled traffic switch. However, for most incremental updates, rolling deployment is the default choice because of its balance of simplicity, cost, and safety.
Memory Tip
Think: "Rolling like a wave, one after another, never all at once." The key exam point: rolling updates are sequential, use existing infrastructure, and need backward compatibility.
Covered in These Exams
Current Exam Context
Current exam versions that test this topic — use these objectives when studying.
Related Glossary Terms
A/B testing is a controlled experiment that compares two versions of a single variable to determine which one performs better against a predefined metric.
Two-factor authentication (2FA) is a security method that requires two different types of proof before granting access to an account or system.
Frequently Asked Questions
Can a rolling deployment cause downtime?
In a properly configured rolling deployment, there is no downtime because at least one instance always remains available to serve traffic. However, if the health checks are misconfigured or the application is not backward compatible, users may experience errors or short interruptions.
How do I roll back a rolling deployment?
Most orchestration tools support automated rollback. In Kubernetes, you run `kubectl rollout undo deployment/<name>` to revert to the previous revision. In AWS CodeDeploy, you can configure automatic rollback triggers based on alarms or manual intervention. The rollback process is also gradual, replacing new instances with the old version.
What is the difference between a rolling deployment and a canary deployment?
A rolling deployment replaces all instances sequentially across the fleet. A canary deployment initially routes only a small percentage of traffic to the new version for testing and then gradually increases that percentage. Canary is riskier but allows for more controlled testing with real traffic.
Is rolling deployment always the best choice?
No. If you need instant rollback or want to avoid any period of concurrent versions, blue-green deployment might be better. If you are testing a major change with unknown impact, canary deployment or feature flags are safer. Rolling deployment is best for simple, low-risk updates with backward-compatible changes.
What is the role of a load balancer in rolling deployment?
The load balancer directs traffic away from instances being updated, so those instances do not receive new requests during the update. Once the instance passes health checks, the load balancer re-enables traffic to it. This is crucial for achieving zero downtime.
How do you handle database changes during a rolling deployment?
You must make all database schema changes additive and backward compatible. For example, add a new column as nullable instead of renaming or dropping a column. This ensures both old and new application versions can read and write to the database without errors. Use migration scripts that are applied before the deployment, not during.
Summary
Rolling deployment is a software release strategy that updates an application gradually, instance by instance or batch by batch, to achieve zero downtime and minimize risk. Instead of taking the entire system offline at once, the old version is incrementally replaced with the new version while the service continues to operate. This approach is fundamental to modern DevOps and continuous delivery practices, enabling teams to release updates more frequently and safely.
Rolling deployment matters because it balances cost, complexity, and reliability. It reuses existing infrastructure, so there is no need for a separate environment like blue-green deployment. It also enforces good engineering habits, such as backward compatibility, robust health checks, and automated rollback. For IT professionals, understanding rolling deployment is essential for designing resilient systems and passing cloud and DevOps certification exams.
The key exam takeaways are: rolling deployment provides zero downtime, uses existing resources, supports gradual rollback, and requires backward compatibility. It is commonly compared with blue-green and canary deployments. In exams, look for scenarios that require low cost and zero downtime without the need for instant rollback. Be prepared to interpret configuration parameters like maxSurge and maxUnavailable, and to troubleshoot failed rollouts. Mastering rolling deployment will give you a solid foundation for managing production systems effectively.