Rollback Application Deployments with Flightcontrol

With rollbacks, Flightcontrol can deploy previous builds of your service(s) without forcing a complete rebuild of your application.

When you rollback a service, Flightcontrol will deploy the previous build of your service. If your environment (such as Production) has multiple services, you can choose to rollback all services, or just selected services.

Using Rollback for an Environment

You won't see the Rollback option on your very first successful deployment for a given Flightcontrol environment. The Rollback option will appear after you have more than one successful deployment - and it will only appear on the previous builds. You will find it in the three-dot menu on the right for the deployment:

Clicking the Rollback options menu item will not automatically rollback your environment. A confirmation dialog window will appear, asking you to confirm that you do want to roll one or more of the services in the environment, as well as possibly rolling back the environment variables.

We recommend rolling back both the service and the environment variables, so you know that the deployment is in a good state. However, if the environment variables are not the cause of the issue, you can only roll back the service.

On the confirmation dialog, you can choose which Flightcontrol service to rollback, as well as whether to roll back the environment variables.

After selecting what you want to roll back, Flightcontrol will start another deployment for your environment.

In the Flightcontrol dashboard, you will find a new entry in your deployment history. If you select that entry, you'll see that the deployment was labeled as a rollback.

We show this deployment as a rollback, so that you can easily see the history for your service.

Deploy a Previous Commit

For any previously successful deployment in your environment's history, you can also choose to rebuild and deploy those versions of the service. This does not prompt you to choose which services to deploy - it will deploy all services in the environment. Use the Deploy this commit menu item to start this process.

This will not be as quick as a rollback, because Flightcontrol kicks off the build process. This procedure will probably still be easier than using Git to revert your code, and then pushing the changes to your Git repository. You also are not modifying your repository's Git history.

Rollback Examples

Let's take a look at an example project to show how rollbacks work.

We'll start with a simple project that has two web application services: Front End and Back End, and a database service named Database.

Both services in this application happens to have a /settings page that displays the value of the environment variable CONFIG_KEY. We set this environment variable in the Flightcontrol dashboard for the whole environment, so that all services can access it.

The /settings route in Python looks like this:

@app.route("/settings")
def settings():
    config_key = environ.get('CONFIG_KEY')
    return f"Config Key: {config_key}"

The details of the above code sample don't matter too much - we're displaying the value of the CONFIG_KEY environment variable.

We'll also set the value of CONFIG_KEY to 1.0 in the Flightcontrol dashboard for the environment.

CONFIG_KEY=1.0

If we load the /settings page for the Front End service, we see that the value of CONFIG_KEY is 1.0:

Config Key: 1.0

The Back End service also displays the same value for CONFIG_KEY:

Config Key: 1.0

We'll use this example as a base line to show how rollbacks work.

Deploying a New Version of the Application

Now, let's say that we want to change the settings page to display another line of text - perhaps "Settings". We'll make this change in the Front End and Back End services, and deploy it to our environment.

After a successful deployment, we see that we now have a new version of both of our web services - the database had no change:

If we visit the /settings page for either service, we see that we have the new text:

Settings
Config Key: 1.0

Let's also go ahead and set the CONFIG_KEY environment variable to 2.0 in the Flightcontrol dashboard for the environment.

CONFIG_KEY=2.0

Click the Deploy button in the toast that pops up, or choose the Deploy option from the Deploy menu for the environment to start a new deployment.

Once the deployment process complete, we see that we have a new version of our services, and a new environment variable value. If we visit the /settings page for either service, we see that we have the new text, and the new environment variable:

Settings
Config Key: 2.0

Let's say that we're not happy with this, and we want to roll our changes back. There are a couple of different scenarios here that we can demonstrate, so let's start with the most common - rolling back all services plus the environment variables.

Rolling Back Both Services but not the Environment

We'll start by clicking the Rollback options menu item on the previous commit in the deployment history:

The confirmation dialog will appear. The default option is to rollback all services but not the environment variables. We'll leave the default options, and click the Roll back 2 services button:

Flightcontrol will start a new deployment, and if you open the service panel on the right, you'll see the that the deployment is labeled as a rollback:

After visiting the URL for the /settings page, we see that we have the original text, and the original environment variable:

Config Key: 1.0

Notice that we did not have to do a full build for this to work. Flightcontrol keeps track of the previously built container image, and deploys that to Elastic Container Service (ECS) Fargate for you.

Rolling Back One Service

We can also roll back just one service - for instance, the Front End Service. After clicking Rollback on one of our previous versions, we get the same confirmation dialog. This time, we'll uncheck the box for the Back End service and leave the environment variables unchecked, and then click the Rollback 1 service button:

This will only roll back the Front End service. We'll see a new deployment in the history, and if we visit the /settings page for the Front End service, we see that we have the original text, and the new environment variable:

Config Key: 2.0

If we visit the /settings page for the Back End service, we see that we have the new text, and the new environment variable:

Settings
Config Key: 2.0

After seeing these examples of how rollbacks work, hopefully you find them useful for your application deployments. If you have any questions, or don't see the specific rollback scenario you are interested in, please contact us!