Blue/Green Deployments

You can configure your apps to be deployed using a blue/green strategy, where Porter will keep the older version of your app running (the “blue” version), while it spins up an identical number of replicas for your app using a new build (the “green” version), and waits for the entire environment to be up and running, before switching traffic from the old version (“blue”) to the new version (“green”). Setting up B/G deployments for your app involves modifying your app’s configuration, as well as your build step in your CI system that’s responsible for updating the Porter app after a successful build.

​

Step 1: Modify your apps on Porter

On the Porter dashboard, navigate to the app you’d like to set this up for, and ensure DevOps Mode is selected. The first step is to get the active image tag your app’s running - you’ll find this in the Source Settings section under the Settings tab. Note the image tag that’s currently selected.

Next, you need to navigate to the tab called Helm Values. In this tab, add and modify the config blow below:

bluegreen:
  activeImageTag: <tag>
  disablePrimaryDeployment: true
  enabled: true
  imageTags:
    - <tag>

For <tag>, you’ll need to specify the image tag you noted down earlier. Once done, click Update Values, and wait for your app to be refreshed.

​

Step 2: Modify your build process

This step involves modifying your CI build process to ensure that instead of using the Porter CLI to simply update the Porter app. In your current build process, you’ll see sections that use porter update config to update the image tag being used for the app; we need to add an additional step right after this update, which tells Porter to switch traffic to the new version.

As an example, let’s consider the following Github Action workflow step, that currently simply updates an app on Porter called web-sample with the new image tag:

    porter-deploy-app:
        runs-on: ubuntu-latest
        steps:
            - name: Checkout code
              uses: actions/checkout@v2.3.4
            - name: Set Github tag
              id: vars
              run: echo "::set-output name=sha_short::$(git rev-parse --short HEAD)"
            - name: Update configuration for web-sample
              uses: porter-dev/porter-cli-action@v0.1.0
              with:
                  command: update config --app web-sample --tag ${{ steps.vars.outputs.sha_short }} --stream
              env:
                  PORTER_HOST: https://dashboard.getporter.dev
                  PORTER_CLUSTER: 0000
                  PORTER_PROJECT: 0000
                  PORTER_TOKEN: ${{ secrets.PORTER_TOKEN_0000 }}

To enable B/G deployments in this case, we’ll just add an additional step at the end of this block to switch traffic, like so:

    porter-deploy-app:
        runs-on: ubuntu-latest
        steps:
            - name: Checkout code
              uses: actions/checkout@v2.3.4
            - name: Set Github tag
              id: vars
              run: echo "::set-output name=sha_short::$(git rev-parse --short HEAD)"
            - name: Update configuration for web-sample
              uses: porter-dev/porter-cli-action@v0.1.0
              with:
                  command: update config --app web-sample --tag ${{ steps.vars.outputs.sha_short }} --stream
              env:
                  PORTER_HOST: https://dashboard.getporter.dev
                  PORTER_CLUSTER: 0000
                  PORTER_PROJECT: 0000
                  PORTER_TOKEN: ${{ secrets.PORTER_TOKEN_0000 }}
            - name: Switch traffic to the new app once ready for web-sample
              uses: porter-dev/porter-cli-action@v0.1.0
              with:
                command: deploy blue-green-switch --app web-sample --tag ${{ steps.vars.outputs.sha_short }}
              env:
                PORTER_HOST: https://dashboard.getporter.dev
                PORTER_CLUSTER: 0000
                PORTER_PROJECT: 0000
                PORTER_TOKEN: ${{ secrets.PORTER_TOKEN_0000 }}

Once you’ve saved this and triggered a new set of builds, your CI runner will be able to specify a “green” version of your app, and switch traffic to it once the “green” version is ready.

​

Multiple Revisions

When your app’s being deployed using the B/G deployment strategy, you’ll notice that each deployment causes your app to jump by three revisions:

1. The first revision runs both “blue” and “green” versions in parallel, with traffic being directed towards the “blue” version.
2. The second revision runs both “blue” and “green” versions in parallel, with traffic being directed towards the “green” version.
3. The third - and final - revision removes the “blue” version, after verifying that traffic has been switched properly from “blue” to “green”.