Skip to main content
  1. Home
  2. Deployment
Last updated: 13 Aug 2024

Deployments

On OTT, all applications are set up for continuous deployment to integration, with the majority also having continuous deployment configured for staging and production. Additionally, you can manually deploy a git reference (tag, branch, or commit SHA) of an application to any environment.

Continuous integration (CI) is run on new commits on the main branch, usually from merging a pull request. If the commits pass CI, they are automatically deployed to integration. After deployment, a set of smoke tests run in integration to verify that the application still works as expected.

If the smoke tests pass and the application has continuous deployment enabled, the deployment is promoted to staging. In staging another set of smoke tests run, and if they pass, the deployment will be promoted to production.

For applications without continuous deployment enabled, they will need to be manually deployed to staging and production.

The Release app shows the currently deployed versions of each app and whether an app requires manual deployment to later environments.

Manual deployments

You can manually deploy an application by triggering the “Deploy” GitHub Action workflow for that application’s repository.

This can be done in GitHub’s web interface:

  1. Go to the “Actions” page in the application repository
  2. Select the “Deploy” workflow from the list of workflows on the left hand side
  3. Click “Run workflow”
  4. Input the git reference and environment (ignore the “Use workflow from” option)
  5. Click “Run workflow”

Or using GitHub’s CLI:

gh workflow run -R "trade-tariff/${REPO}" deploy.yml -F environment=${ENVIRONMENT} -F gitRef=${GIT_REF}

Manual deployments are never promoted to other environments.

Overview of the deployment process

This is an example deploying an application to integration:

  1. Developer merges a PR into main branch and it passes CI
  2. Triggers the “Deploy” workflow in GitHub Actions
    1. Builds and pushes an image to AWS Elastic Container Registery (ECR) in production
    2. Sends a webhook to Argo Workflows in production
  3. Triggers the “deploy-image” workflow in Argo Workflows in production
    1. Updates the image tag reference for integration in govuk-helm-charts with a new commit
    2. Adds a “deployed-to-” tag on the image in ECR
    3. Notifies the Release application of the deployment
  4. Argo CD in integration polls govuk-helm-charts and detects updated image tag reference
    1. Triggers sync of the app-config (app-of-apps) application in Argo CD
    2. Updates the Helm values for the deployed app’s Argo CD application resource
    3. Updates the Kubernetes deployment resource with the new image tag
  5. Kubernetes does a rolling update of the pods
  6. Argo CD triggers the “post-sync” workflow in Argo Workflows in integration
    1. Runs smoke tests for the app
    2. Checks if deployment should be promoted
    3. If so, sends a webhook to Argo Workflows (in production) to trigger deploy-image for the next environment.

Troubleshooting

If your release does not make it to production:

  1. Updates on status of Argo workflows are posted in #govuk-deploy-alerts.
  2. Click on View workflow for your failed deployment.
  3. You may be presented with am ugly login error, in which case try logging out, logging in and then clicking the view workflow button again.
  4. The argo workflow will display a list of steps. To investigate the reason for failure, click on the failed job, and from the summary panel click on LOGS.
  5. If the failure is due to a flakey smokey test, you can hit the RESUBMIT button for the full workflow.

More in the Deployment section

Learn

How to...