The development pipeline
When responding to a security incident, you should make any code changes in private, so that you don’t accidentally disclose the vulnerability. To do this, follow the instructions for making a repo private.
Our development and deployment pipeline looks like this:
- Open a Pull Request (PR)
- Wait for Continuous Integration to pass
- Review your own changes
- Get someone to review your Pull Request
- Check for or implement a deploy freeze
- Merge your own Pull Request
- Deploy through each of the environments
Wait for Continuous Integration to pass
When a Pull Request (PR) is opened, it often triggers an automated job, which typically lints the code and runs the tests.
Read about Continuous Integration checks.
Review your own changes
As well as double-checking your code and commits, you may refer to the following:
Heroku App Review
Sometimes you may need to demo a running version of your change. All frontend applications and some publishing apps have Heroku Review Apps enabled, with a link near the bottom of each PR.
Branch Deploy Review
Sometimes you may need to deploy your change in Integration in order to test it works on real infrastructure. Refer to the manual deployments documentation.
Get someone to review your Pull Request
The GDS Way has guidelines on how to review code.
Only when the tests pass and the code has been approved the Pull Request can be merged, since we’ve configured GitHub to prevent merges otherwise.
Check for or implement a deployment freeze
We sometimes have a deployment freeze on applications, e.g. during periods where accidental bad deploys would be particularly disruptive, such as during an election.
You should check whether or not there is a code freeze in effect by referring to the relevant section in the deployments documentation.
Merge your own Pull Request
We’ve got guidelines on merging of Pull Requests.
Some applications have restrictions on who can merge PRs. If you are unable to merge your own PR, you should ask someone else to merge (and deploy) it for you.
Code that is merged to main is tested again on CI. This is because
the main branch may have changed since the tests last ran on the PR.
WARNING: some applications have Continuous Deployment enabled, which means the deployment process is fully automated. You should do any manual testing with a temporary, branch deployment before you merge.
Deployment
Teams are responsible for deploying their own work. We believe that regular releases minimise the risk of major problems and improve recovery time.
Refer to the deployments documentation.
After a deployment:
- Check Sentry for any new errors.
- Check the Deployment Dashboard for any issues.
- Run a build of end-to-end tests in the environment you’re deploying to.