Choosing a deployment strategy

Overview

Whenever you update your application code, you can adjust two aspects of the way it is updated:

1. How the updated code is pushed to your servers (the deployment strategy)
2. 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:

1. Serial deployment
2. Parallel deployment
3. Rolling deployment

We cover how to set the strategy for your application, as well as the pros and cons of each strategy below.

Changing your application's deployment strategy

There are three ways to set a deployment strategy for an app:

1. Using the Dashboard and selecting "Deploy with options"
2. Creating a deployment profile that defines a strategy
3. 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 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.

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:

1. From your app dashboard, click on the green Deploy button and then the Create New Profile link.
2. Name the profile
3. Choose a deployment strategy
4. Choose which components will be deployed (optional)
5. Define upgrade settings (optional)
6. Save the profile

To deploy using a profile:

1. From your app dashboard, click on the green Deploy button
2. 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:

• serial
• parallel
• rolling

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).

Serial deployment

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.

Parallel deployment

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.

Rolling deployment

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:

1. 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).
2. The first group is taken off the load balancer, deployed to in parallel, then added back to the load balancer
3. If the first group deploys successfully, the second group will then be taken off the load balancer, deployed to in parallel, then added back
4. If either group deployment fails, it will not be added back to load balancer and deployment will stop.
5. When deploying again, the previously failed group (if present) will always go first

You can tag your application servers as either c66.deployment.group.sapphire or c66.deployment.group.emerald to indicate your preference for grouping.

Pros and cons of each deployment strategy

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_adding_servers and 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).