Skip to main content
Last updated: 6 Dec 2024

Deployments

On GOV.UK, 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 to a specific environment by triggering the “Deploy” GitHub Action workflow for that application’s repository. Manual deployments are never promoted to other environments.

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 the “Run workflow” dropdown
  4. Input the git reference (e.g. branch name or commit sha) and environment (ignore the “Use workflow from” option)
  5. Click the “Run workflow” button

Or using GitHub’s CLI:

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

When the workflow completes, you’ll need to wait for the deployment to propagate.

  1. Navigate to the Argo app overview for your app and environment (e.g. Whitehall on integration)
  2. Click on the “Details” button and check that the “ANNOTATIONS” label references the commit sha you provided earlier. You can speed things along by clicking the “Sync” button.
  3. Finally, check that the “Deployment” pod for your app (e.g. deploy: whitehall-admin) is not still being promoted (should have green tick).

Nudging Argo to speed up deployments

Deployments are triggered by changes to app-config/image-tags, which Argo polls periodically. This includes image tags for all of the app repositories (e.g. Whitehall).

If you don’t want to wait for Argo to poll the app-config chart, you can click the Refresh button in the app-config application in Argo (e.g. app-config on integration).

This will then automatically trigger a Sync of any applications with changed image tags, which will ultimately update the deployment.

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 GitHub Packages
    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. 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
    4. Images are pulled-through AWS Elastic Container Registry (ECR) in production from GitHub Packages
  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 end-to-end test, you can hit the RESUBMIT button for the full workflow.