rolling deployment
What is a rolling deployment?
A rolling deployment is a software release strategy that staggers deployment across multiple phases, which usually includes one or more servers performing functions within a server cluster. Rather than updating all servers or tiers simultaneously, the organization installs the updated software package on one server or subset of servers at a time. A rolling deployment helps reduce application downtime and prevent unforeseen consequences or errors in software updates.
How rolling deployment works
In a traditional software upgrade, an application's servers are taken offline while its software is updated and tested, then it is returned to service. This can result in substantial downtime for an application -- especially if unexpected errors or problems force a developer to revert the installation to a previous version.
In a rolling upgrade, only part of the server capacity for an application is offline at a given time. For example, consider a three-tier application comprising front end, back end and database, deployed with three nodes in each tier. Each of the three front-end application server nodes receives traffic through a load balancer. In a traditional upgrade, the load balancer closes all application traffic for the servers to go offline and update. In a rolling deployment, the organization can take one of the nodes in each tier offline, with the load balancer configured to direct traffic to the remaining servers still running the current software version. The idle servers receive updates and testing; the remaining online servers support user traffic.
The number of simultaneous deployment targets in a rolling deployment is referred to as the window size. A window size of one deploys to one target at a time, and that deployment must finish before another deployment starts. A window size of three deploys to three target servers at a time. A large cluster might use a larger window size.
A rolling deployment might include a testing phase wherein the load balancer directs only limited or test traffic while the new software is configured and proven. This does not affect the experience of users still accessing the application on the not yet upgraded remaining servers.
After the software tests successfully, the server returns to service and another server node is taken offline to repeat the process. This continues until all the server nodes in the cluster are updated and running the desired application software version. The overall application has been continuously available throughout the rolling deployment.
In a rolling deployment, updates are applied in segments, which prevents noticeable performance hits to application users.
Rolling deployment considerations
For a successful rolling deployment, IT teams must ensure backward compatibility across the stack. Some nodes might be running newer versions while others are still on older versions during a rolling deployment. Older versions of web or application components must work with new database schema, or vice versa.
Session persistence can be an issue with rolling deployments if user traffic is directed to servers that are running different software versions, with unpredictable and undesirable results. Load balancers should support user persistence functionality so that user traffic can continue on the same application server. In addition, session-sharing should be invoked wherever possible so that the user session can continue on another server if the server currently providing user persistence is taken offline for its update.
Rolling deployment vs. blue/green and phased deployments
Rolling deployments do not require as much underlying IT resource capacity as blue/green deployments, because the update occurs on one entire production environment while an identical production environment runs the previous software version for users.
In addition, rolling deployments differ from phased rollouts. A phased deployment occurs over an extended time span and users know that they're on different software versions so organizations can gather feedback or test out performance before fully rolling out a change.
