Skip to content

Latest commit

 

History

History
94 lines (69 loc) · 3.59 KB

releases-and-deploys.md

File metadata and controls

94 lines (69 loc) · 3.59 KB
Raw

Releases and deployments

Introduction

We have three environments we can deploy to, all hosted on DfE CIP Azure tenant:

  • development
  • test
  • production

We have separate release and deployments so that we can have fine grained control of what code is deployed where.

The development environment tracks the main branch, with the other environments have specific releases base on tags.

Product reviews

We like to review a release with our product owner and anyone else on the team before we release and deploy. This is a great opportunity to ensure the quality of our work, the features meet expectations and that we haven't missed anything, it is also a great time to come together and look at what we are building!

Product reviews are not required, but strongly encouraged and should be done before we tag the release, doing so allows us time to fix any issues highlighted in the review.

Releases

Changes are collected together in a sequentially numbered release that can then be deployed to one of our environments.

We should aim to create a new release at least once per sprint, but we have the flexibility to release as often as needed.

Creating a release

  • create a new branch off main called release-x where x is the next release number in the sequence.

    You can check the releases in GitHub or locally with git fetch --tags & git tag.

  • Update the CHANGELOG.md: add a release-x heading under the unreleased heading and update the links at the bottom of the file.

  • Commit this change with git commit -m "release-x".

  • Push this branch and open a PR.

  • You can use the release checklist as the PR message and to ensure all steps are completed.

  • Get this PR reviewed and approved, once approved, merge into the main branch.

  • Tag the merge commit with release-x with git fetch & git tag release-x commit-sha where commit-sha is the SHA of the merge commit.

  • Push the tag with git push --tags

  • Create a new Release in GitHub, reference the release tag and paste in the changes from CHANGELOG.md into the release.

Deployments

A deployment applies the changes in a release to an environment with the exception of the development, which instead simply tracks the main branch.

We should aim to deploy to production at least once per sprint, we have the flexibility to deploy as often as needed.

Deploying

To deploy a release to either test or production environments, go to GitHub Actions for the repo, and select 'Deploy to Environment' from the sidebar.

A button will be visible in the top right corner labelled 'Run workflow'. Clicking this button will open a modal window where you will be prompted with the following options:

  • Use workflow from:
    • Select the dropdown, then click 'Tags' and select your 'release-x' tag.
  • Choose an environment to deploy to:
    • Select 'test' or 'production' as appropriate

Note: you must do these steps in order to prevent the environment defaulting back to 'development'!

Clicking the 'Run workflow' button will kick-off a deployment with your specified options.

The Docker image will be built, then pushed up to a container registry, and then both Azure Container Apps (web app & worker) will be restarted with the latest image.