Choosing a deployment strategy
Whenever you update your application code, you can adjust two aspects of the way it is updated:
- How the updated code is pushed to your servers (the deployment strategy)
- How the updated version is shown to customers (the rollout strategy)
This guide is concerned with the first aspect - how the new code gets to your servers.
If you need help with the second aspect - how the new version of your application is presented to your customers - please read our separate guide to rollout strategies.
Types of deployment strategies
Your application’s deployment strategy dictates how we push changes out to your servers. There are three strategies available:
- Serial deployment
- Parallel deployment
- Rolling deployment
We cover how to set the strategy for your application, as well as the pros and cons of each strategy below.
Cloud 66 defaults to the best available deployment strategy for your web server. For webservers that support rolling restarts (Puma, Unicorn, Passenger Enterprise) we will default to parallel deployment. For Passenger Community, we will default to serial. You can override this decision at any point choosing any of the available strategies.
Changing your application’s deployment strategy
There are three ways to set a deployment strategy for an app:
- Using the Dashboard and selecting “Deploy with options”
- Creating a deployment profile that defines a strategy
- Setting deployment strategy using Cloud 66 Toolbelt
Using “Deploy with options”
You can trigger a deployment that uses any of the three strategies by clicking the Deploy button on your Application Overview page and choosing Deploy with Options. This will allow you to choose between the three strategies.
This will only apply to the current deployment - it does not change the default deployment strategy for your app.
You won't be given the option to choose a deployment strategy unless you have multiple servers.
Using a deployment profile
Deployment profiles allow you to customise how your app will be deployed, including the deployment strategy it should use.
To create a profile:
- From your app dashboard, click on the green Build button and then the Create New Profile link.
- Name the profile
- Choose a deployment strategy
- Choose which components will be deployed (optional)
- Define upgrade settings (optional)
- Save the profile
To deploy using a profile:
- From your app dashboard, click on the green Build button
- Click on the name of the profile you’d like to use for this deployment
For more information on deployment profiles, please read our reference guide.
Using the Toolbelt command line
You can use Toolbelt to set the deployment strategy for an application. The command is
cx setting set deploy.strategy <strategy> and valid values for the
strategy parameter are:
This is a persistent change to your app’s deployment strategy - the app will use this strategy for all future deployments (until you change this setting).
How deployment strategies work
All the deployment strategies have a few things in common:
- Database migrations always occur first, regardless of strategy. Given that some of your servers will be running legacy code for a (hopefully short) period, you should follow best practice around migrations. For example, don’t delete columns/tables that are currently in use by legacy code.
- By definition all three strategies require at least some of your servers to be unavailable during deployment - the only difference is how many servers, and for how long. If your application has no redundancy, we strongly recommend scaling your application up (even temporarily).
If you're planning to use parallel or rolling deployments, we recommend adding health checks to your deployment process.
In this strategy we deploy to each server one at a time. We take each server off the load balancer and then add it back once the deployment has succeeded. If a server fails to deploy we will halt the process and alert you.
In this strategy we deploy to all your server simultaneously. Servers are not taken off the load balancer. If your webserver does not support zero-downtime reloads you will most likely have some downtime while your application reloads.
In order to use rolling deployments, your application needs:
- A load balancer
- At least four servers (not including the load balancer)…
- …two of which must be web servers
Rolling deployments work as follows:
- Your servers are split into two groups based on a heuristic that takes factors like server size into account. The groups are balanced by server load and role (as far as possible).
- The first group is taken off the load balancer, deployed to in parallel, then added back to the load balancer
- If the first group deploys successfully, the second group will then be taken off the load balancer, deployed to in parallel, then added back
- If either group deployment fails, it will not be added back to load balancer and deployment will stop.
- When deploying again, the previously failed group (if present) will always go first
You can tag your application servers as either
c66.deployment.group.emerald to indicate your preference for grouping.
We strongly recommend adding deployment success checks to your application to help catch a wider range of errors (i.e. errors that may not disrupt code deployment but that nonetheless break your application).
Pros and cons of each deployment strategy
|Serial||The safest option - only one server is ever affected||The slowest option with a long period of overlap between old and new code being served|
|Parallel||The fastest option with a very brief overlap of old and new code being served||The riskiest strategy - a bad deploy can impair all your servers. Will result in some downtime for webservers that don't support live reloads|
|Rolling||A balance between safe and fast. Very brief overlap of old and new code being served||Requires at least 4 servers and a load balancer. Half your servers will be unavailable during deployment so load on the application needs to be managed carefully|
Coping with load balancer configuration lag
Load balancers - particularly native cloud load balancers - can be prone to configuration lags. In other words, they can sometimes report that they have removed a server whereas, in reality, some traffic is still being routed to that server for a few seconds or minutes.
This can also work in the opposite direction - the load balancer may report that it has added a server but it does not actually begin routing traffic to a server for a short period.
For many lag-tolerant applications this short delay does not matter, but some applications are more sensitive and can suffer adverse affects from this configuration lag.
If your application is “lag-sensitive” we recommend adding short delays to your load balancer configurations. You can do this using the
wait_after_removing_servers options under the load balancers section of your application’s manifest file.
Bear in mind that adding these delays can slow down the deployment process significantly. For serial deployments the additional delay will be:
(wait time per server)x(number of servers) = (extra deployment time).
If you use this option in your manifest, subsequent deployments will use the value set. To remove this delay, set the value to
0 in your manifest, and then redeploy. Simply deleting this value from your manifest will not result in removing the setting once it has been applied.