Rolling deployments
Last updated
Last updated
Release automatically handles most aspects of rolling deployments for you. This means that when you push code changes, your applications will not face any downtime.
A rolling update does not apply code changes to all of your nodes at once, but rather works as follows:
Nodes in your cluster are terminated one at a time and replaced with new nodes running the new version of your software.
While each node is down, traffic is routed only to the healthy nodes. For a short while, some users may see the new version of your software while others still see the old version.
The update process for each node is started only after the previous node comes up and is confirmed healthy.
As you can see in the diagram below, during a rolling update, the majority of nodes are available to serve traffic at all times.
You can read more about how rolling deployments work in the Google Cloud documentation, but note that Release handles this for you automatically and there is no need for you to follow the steps listed on that page.
While rolling deployments work well for many use cases, they may not always be appropriate. For example, you may need to be sure that all your users see the same version of your software. With rolling updates, it can be difficult to know which version of your application users are accessing at a given point in time.
Database migrations can also be tricky with rolling deployments. If you need to add or rename a database column, for example, you'll need to be careful with your application code and the order your changes are applied to ensure that your database logic can handle both the old and the new application code.
An alternative to rolling deployments is blue-green deployments. With this model, you have two copies of your environment, one "blue" and one "green". Only a single environment is user-facing at any given time. When you deploy changes, you deploy them to the non-user-facing environment, and only once all changes are completed and confirmed working do you switch all users to the new environment simultaneously.
This can result in cleaner updates, but it also means that any bugs or issues will affect all of your users. Traditionally, the blue-green deployment model is also associated with higher costs, as you have to maintain two full instances of your complete infrastructure.
Because Release gives you environments as primitive building blocks, you can extend the blue-green deployment model further. Instead of having only two environments, you can add as many "colors" as you need, having a completely new environment for every change. We call these rainbow deployments.
Please contact us if you would like to use rainbow deployments with your account, as this is currently a manual feature that we activate for you.
