A rolling deployment is a software release strategy that staggers deployment across multiple phases, which usually include one or more servers performing one or more function 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 is used to reduce application downtime and unforeseen consequences or errors in software updates.
In a traditional software upgrade, an application servers is taken offline while its software is updated and tested, then it is returned to service. This can result in substantial downtime for the 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 proven, 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 remaining servers that are not yet upgraded.
After the software is tested successfully, the server returns to service and another server node is taken offline to repeat the process, continuing until all of 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.
One of the important concerns for a rolling deployment is ensuring backward compatibility across the stack. Some nodes might be running newer versions and others are still on older versions during a rolling deployment. The organization must ensure that the older versions of web or application components 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 does not require as much underlying IT resource capacity as blue/green deployment, wherein the update occurs on one entire production environment while an identical production environment runs the previous software version for a user.
Rolling deployment differs from phased rollouts. A phased deployment occurs over an extended time span and a user is aware that he's on different software versions, in order to gather feedback or test out performance before fully rolling out a change.