Sometimes when it’s time to deploy a new feature, there’s no way to test it properly without actually putting it into production. Maybe you’ve got to use the production environment and networking to be sure everything is OK with the new version, or maybe you won’t know if a new feature works until it’s in use.
One way to handle that is with a dark launch. You can use dark launches to provide new features to only certain users or to test new features without changing how the main production system works for most users. There are lots of ways to handle a dark launch, depending on how you want to make the new features selectively available. I’ve described one way in Revealing new features slowly with dark launches.
In short, I’ve used resource tags to identify the nodes on my production environment. Like in the article Configuring your applications for rolling deployments, I put geographical tags on the nodes so I can control where I want to deploy the new version:
Now I can run a process with that tag as an argument. The process removes the nodes with that tag from the load balancer so no users access the dark launch node. Then, the process deploys the new version of the application to only the nodes with that tag. Now one of my nodes is running the new version of the application, and people with the direct URL can access it and try it out. I could set my load balancer to send a little traffic to the new version to see how it works, or I could use it strictly for my own internal testing.
When it’s time to go live on every node with the new feature, I run a similar process that updates each node and enables all nodes on the load balancer.
That’s just one way to handle a dark launch in IBM UrbanCode Deploy. Let us know if you’ve got other strategies or different requirements for your applications.
Read the article here: Revealing new features slowly with dark launches.