Updates get more complicated when your application runs on many nodes. Updating all of the nodes at once might seem simple and easy, but it increases the risk of downtime and problems if the updated version has a bug. It’s better to send the deployment to one or a few servers at a time in a rolling deployment.
Rolling deployments can be complicated or simple. For example, the rolling deployment can include a dark-launch phase in which an updated node is not in use by the customers. You can also use a rolling deployment as part of a blue-green deployment, switching nodes from the blue environment to the green environment one at a time. For more information about blue-green deployments, see Setting Up Blue-Green Deployments in IBM UrbanCode Deploy 6.2.4.
All you need to do to set up a rolling deployment is to make sure that no more than one (or a small number) of your nodes are updated at a time. There are many ways to do that, so I’ll illustrate two straightforward ways.
Running updates on one agent at a time with the For Each Agent loop
The For Each Agent step is a loop that runs over the agents that you select. You can run any tasks inside the loop that you would normally run in an application process, including deploying components, calling generic processes, and running tests. The loop has a setting to limit the number of agents to run on at the same time, so you can set it to 1 to deploy to a single agent at a time and pause in between for testing.
For example, here’s an environment that has four database nodes and four web application nodes. The database nodes host a database component, and the web nodes host a web component.
An application process can deploy to those nodes in many different ways. Suppose that you want to update all of the database nodes first, one at a time, running an automated test each time. Then, you update the web nodes, one at a time, running an automated test each time. In this case, you need two For Each Agent loops: one for the database nodes and one for the web nodes, as shown in the following application process:
To make sure that the update runs on only one node at a time, set the step property Max Concurrent Agents to 1:
If the update is long or error-prone, you could also include steps that remove the node from the load balancer so no traffic goes to it during the deployment, and then restores traffic to it if the deployment is successful.
That’s all there is to it. Now when you run the application process and select versions as usual, the process updates the nodes one at a time.
Running updates according to resource tags with the For Each Tag loop
You can take finer control over how the nodes are updated by applying resource tags to them and using the For Each Tag loop, which is available in IBM UrbanCode Deploy version 6.2.4 and later. This step is a loop like For Each Agent, but it runs according to the tags that you apply to resources.
Resource tags give you more flexibility because you can apply them in any way that you want. For example, if you have nodes in different geographic areas, you can apply tags based on those areas. The following figure shows an application environment in which multiple nodes are tagged “Africa,” “Europe,” “North America,” and “Asia:”
Here is a topology diagram for this scenario. In this case, each region has a database server and a web server, but the regions could have many servers each. The important part is that they are grouped together by geographical region. This way, you can update one region at a time, perhaps when one region is in night-time and not as active. The active regions can absorb the load from the inactive region.
The application process for this deployment only needs one For Each Tag loop. The loop updates the database for the specified geographical area, then it updates the web application for the same geographical area, and then it runs automated tests.
The settings for the loop let you select the resource tags to run on and the order for those tags. Also, like the For Each Agent loop, the For Each Tag loop has a setting to limit the number of concurrent tags. So to run the update on one geographical tag at a time, set the Max Concurrent Tags property to 1.
When you request the process, you can adjust the tags on the fly, adding and removing tags and changing the order:
You can set up resource tags just about any way you want. For another example, if you want to update all database nodes first and then all web application nodes second, you can apply resource tags to the database nodes and web nodes, and then run the deployment based on those tags. In this case, I’ve tagged the resource containers as “database” and “web,” and the tag applies to all agent resources that are under those containers:
The application process is exactly the same as the process with the geographical tags:
However, in the loop properties, I’ve selected the “database” and “web” tags:
When I run the application process using the “database” and “web” tags, the loop runs once for each tag. The first time the loop runs, the database component is installed to the nodes with the database tag. The web component is ignored because it is not mapped to any resources that have the database tag. The second time the loop runs, the web component is installed to the resources that have the web tag.
Those are just a few ways to organize rolling deployments for your applications. The For Each Tag and For Each Agent loops give you lots of flexibility to organize and stage your deployments in any way you want, whether your strategy includes blue-green deployments, canary deployments, rolling deployments, or other DevOps deployment strategies.