When you’ve got an application running on multiple nodes, it’s usually a good idea to update a few tester nodes first, before updating every node. That way, you can make sure that the new version of the app is running as you expect on the canary nodes before you commit to updating every node. You can run any automatic or manual tests that you want, tracking the users who are sent to the canary node, before you update the other nodes. If something goes wrong on the canary nodes, you can cancel the upgrade and continue using the nodes that haven’t been upgraded.

I include a canary node as part of a blue-green deployment scenario in Setting Up Blue-Green Deployments in IBM UrbanCode Deploy 6.2.4 and the related video, but I’m going to explore canary nodes here in a little more detail.

There are a few ways to set up a node as a canary node in IBM® UrbanCode™ Deploy, but the way that seems the most straightforward to me uses resource tags. Resource tags are labels that you assign to resources, particularly agent resources. With resource tags, you can identify groups of agents in any way that you want. Then you can run processes on only the agents with a specific tag. So, to deploy to a canary node or nodes first, give them a tag such as “canary” and set up your process to deploy only to those nodes first. If the canary deployment goes well, you can then deploy to the rest of the nodes.

Setting up the canary deployment

As you might have guessed, the first step is to apply the resource tags to the resources in the environment. I’ve used the tags “canary” and “mainSystem” that I used in the blue-green deployment demo in the following application environment. It’s got one canary node and two non-canary nodes.

Here’s how the topology looks:

A simple way to deploy to nodes by tags in IBM UrbanCode Deploy version 6.2.4 is to use the For Each Tag step. This step is a loop that runs over all resources that have the given tag or tags. For example, here’s a simple application process with a For Each Tag step. Inside the step is a sub-process that runs for each resource that has the specified tag or tags.

In the loop properties, I select the tags to run on. Here I’ve selected just the canary tag, but I’ll show you how to change that later.

That’s it; the server knows to run the steps in the loop on only the resources with matching tags. So, to deploy to my canary node, I start the application process, give it the new versions of the components as usual, and leave the default canary tag in the process request:

The process updates only the nodes with the canary tag; in this case, only one of the three nodes is updated. After the process runs, the inventory and compliance for the environment show that only one of the three nodes is running the requested version. That’s what the request intended to do, but it still means that the environment is noncompliant because not all nodes match the process request.

But the flexible part is that I can change the tags for a specific process request. When I’m ready to move all nodes to the new version, I run the same application process again, giving it the same version but the mainSystem tag instead of the canary node.

Now all nodes are up to date and the inventory is compliant:

That’s a simple way to run a canary deployment with resource tags. That method is fine if you don’t mind the manual work of requesting the same application process twice. Automating everything into a single process is better because I know it’ll run the same way every time. So here are two ways to update both the canary nodes and the main nodes in a single run of an application process:

Using two tags in the For Each Tag step

One way to deploy to both tags in one process is similar to the way I handled the canary node in the article Setting Up Blue-Green Deployments in IBM UrbanCode Deploy 6.2.4 and the related video. If you don’t want to have to run the process twice, you can set up the application process to update the canary node first and the rest of the nodes second.

One way to do that in a single process is to include automatic or manual tests as part of the For Each Tag loop. Then, because the order of the resource tags in the process determines the order in which they are updated, you set the canary tag to run first and the mainSystem tag to run second. This way, the process updates the canary node first, runs the tests, updates the main nodes, and runs the tests again. You can include rollback steps in case any deployments or tests fail. The process can be as simple as a single deployment in one step and a test in another step. I’ve also added a rollback step in case anything goes wrong.

Then, when you request the process, you put the canary tag first and the tag for the rest of the nodes second:

Using multiple For Each Tag loops

Another way is to use multiple For Each Tag loops, with automatic or manual tests between them. In the following example, the first loop handles the canary nodes and the second loop handles the other nodes. You can include any automatic testing, manual testing, or approvals between the loops.

The only trick to this process is that, when I request the process, two loops are shown in the request. I’ve got to remember to put the canary tag in the first loop and the mainSystem tag in the second:

Those are just a few ways of modeling and deploying to canary nodes to make sure everything is working right before you deploy new applications to all of your nodes. Let us know if you’ve got other ways to do this or questions about how to make this work in your scenario.