Rainbow deployments

This is an opt-in Enterprise feature. Please contact us on [email protected] if you want to enable it on your account.
Rainbow deployments are an extension of the popular Blue-green deployment pattern.
  • With Blue-green deployments, you have two copies of your production environment, "blue" and "green", with one being the active production environment at any given time. When you deploy changes, you deploy them to the other one and then switch it to being the active one. This means that your development and production environments remain closely mirrored by default.
  • With ReleaseHub, you have easy access to unlimited environments, so we extended the Blue-green pattern to infinite colors of the rainbow. Each deployment happens in a Namespace, which is a copy of your production environment. Each Namespace gets a color, and you can have as many colors as you need.
You can think of these deployments as lanes on a highway: two lanes are better than one, but infinite lanes are better than two. Let's say you are currently running version 1 of your software in the blue environment and you deploy version 2 to the green one. You switch "blue" over to your main environment and direct user traffic there, while keeping "green" running to complete a few asynchronous jobs that still need to complete. Now you discover a problem with version 2 and deploy a hotfix. If you're stuck with only two environments, blue and green, you have to choose between killing the jobs running on green or pushing new code directly to your live environment. If you have infinite colors available, you can keep both the previous environments running (red and orange for example), while starting a new one (yellow).
Rainbow environments
We use Rainbow deployments internally at ReleaseHub, so we'll be happy to help you decide if they are a good fit for you and how to use them effectively in your specific case.

How to use Rainbow deployments

After the feature has been activated in your account, you will be able to configure Rainbow deployments through your Application Template file. Note that it only works for permanent environments, not ephemeral ones. You'll specify a timeout period and how many active environments you want, as described in the next section.
If you activate Rainbow deployments in an environment, you'll see a rainbow icon to indicate that it is active for that environment, as shown below.
rainbow icon
This will also activate the Namespaces tab where you'll see a number of sub-environments, each with their own color, as shown below.
Namespaces tab
When you do a new production deployment, it will automatically go to a new namespace and get a new color. It will immediately become the active namespace in that environment. The previous namespace will stay alive for a configured timeout period.
This timeout period is useful in case you have long-running jobs or other tasks that need to complete before the environment disappears.
  • After the timeout, the old namespace will be removed.
  • If you re-deploy exactly the same build, it will still create a new namespace and expire the previous one, but the color won't change.

Configuring Rainbow deployments

To turn on Rainbow deployments in a specific environment, add the following block to your Application Template YAML file.
type: infinite
termination_threshold: 180.minutes
  • The type value defines the kind of Rainbow deployment. Currently, we only support infinite for this value, which means that there is no limit to how many namespaces can be created in an environment.
  • The termination_threshold value specifies the timeout for environments to stay alive after a new one is deployed. You can set this in seconds, minutes, or hours, and you should choose a value that is larger than the longest running job or process you have to avoid losing any in-progress work happening in a specific namespace.
Note that the termination_threshold is applied when the namespace is created, so if you update it and redeploy your build, then your existing namespace will still terminate after the previously defined value has elapsed.

State and state changes for Rainbow deployments

A namespace can take on one of several states. These are:
  • Active: the currently active environment, also indicated by an arrow in the list of namespaces.
  • Pending: the namespace is initializing with your configuration. This state should only last a few seconds, before moving into Activating.
  • Activating: the namespace that will be active next. As soon as it is ready, it will become active and the previously active namespace will become Inactive.
  • Inactive: any previously active namespace that has not yet been destroyed. You'll see a countdown timer next to these indicating when they are due for termination.
  • Destroyed: any previously active namespace that has passed its termination_threshold. You can still see information such as the build number, configuration version, and creation time for these environments.
There are two icons with arrows to the left of the namespaces that show the currently active environment and (if applicable) the next environment that will activate. You can see these below.
Inactive environments show a timer indicating when they will be destroyed. You can see this below.

Namespace details

By clicking on the color for any namespace, you'll see a namespace details page which will show the same information (name, time until removal, deployment ID, and version) as you can see on the overview page, but also show a list of instances running in that namespace.
namespace details

What lives inside Rainbow environments?

In an ideal world, Rainbow deployments mean creating infinite copies of all resources that make up a given environment. In reality, it is not practical to have infinite copies of resources such as your production database or Apache Kafka instances, and therefore these resources often live "outside" of this setup.
You'll have to structure your systems carefully so that you don't, for example, have conflicts when several expired but not destroyed environments are competing for the same external resources.

Choosing colors

In case you wonder how the colors are chosen, we use the short git hash which is conveniently a six-character hex number, which can translate directly to a hex color code.