Rainbow deployments

This is an opt-in Enterprise feature. Please contact us at [e-mail] if you want to enable rainbow deployments 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". Either the blue or green environment is the active production environment at any given time. When you deploy changes, you deploy them to the environment that is not currently active and then switch the recently changed environment to active. This means that your development and production environments remain closely mirrored by default.

• With Release, you have easy access to unlimited environments, so you can extend 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" environment. 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 while starting a new environment, "yellow", for example.

Rainbow environments

We use rainbow deployments internally at Release, so we'll be happy to help you decide if they are a good fit for you and advise you on using them effectively in your specific case.

How to use rainbow deployments

After the rainbow deployment 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 can see a number of subenvironments, each with its own color, as shown below.

Namespaces tab

A new production deployment will automatically go to a new namespace, get a new color, and 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 redeploy 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 rainbow deployments on in a specific environment, add the following block to your Application Template YAML file:

rainbow_deployment_configuration:
    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 environment is deployed. You can set this in seconds, minutes, or hours, and you should choose a value greater than the longest-running job or process in that namespace to avoid losing any in-progress work.

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 inactive namespaces 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 in the image below.

statuses

Inactive environments show a timer indicating when they will be destroyed. You can see this below.

expiring

Namespace details

By clicking on the color for any namespace, you'll see a Namespace Details page that shows the same information (name, time until removal, deployment ID, and version) as you can see on the overview page, as well as 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. Therefore, resources like this 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 resource.

Choosing colors

In case you wonder how the colors for environments are chosen, we use the short Git hash (conveniently, a six-character hex number) and translate it directly to a hex color code.