You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our default branch for making changes is `main`: new features and non-urgent
4
-
bug fixes should be merged into here.
3
+
The `next` branch is used to collect and test changes before a release. Only
4
+
changes scheduled for the next release should be in `next`, and commits may be
5
+
reverted or added to reflect scope changes.
5
6
6
-
The `release` branch is a reference to what is in production at any point in
7
-
time. It usually tracks `main` but can also point to hotfix branches as
8
-
necessary.
9
-
10
-
Releasing basically follows these steps:
11
-
12
-
1. Create a release candidate by tagging `main` (e.g. `v1.0.0-rc1`)
13
-
2. Create a release in GitHub and add information about the changes. Update the
14
-
assurance statement.
15
-
3. Create a release by fast-forwarding or resetting `release` to the release
16
-
candidate, and creating a tag (e.g. `v1.0.0`)
17
-
18
-
```mermaid
19
-
gitGraph
20
-
branch release
21
-
commit tag: "v0.9.9"
22
-
checkout main
23
-
commit tag: "v1.0.0-rc1"
24
-
checkout release
25
-
merge main tag: "v1.0.0"
26
-
```
7
+
Once a release has gone through the assurance stops and ready to release, `next`
8
+
is merged into `main` using a PR, and then `main` is deployed out to production.
27
9
28
-
Details below.
29
-
30
-
## Pre-release and testing
31
-
32
-
Changes merged into `main` are deployed to the `qa` and `test` environments for
33
-
testing. When there is a large batch of PRs to merge at once, after a
34
-
merge-freeze for example, only merge a few at a time to try to make it easier to
35
-
trace any issues that arise during testing.
36
-
37
-
## Release candidate
38
-
39
-
Once all the necessary changes are merged and have been tested, create a
40
-
release candidate by creating a tag on the `main` branch. e.g. `v1.0.0-rc1`.
41
-
42
-
Create a [release in GitHub](https://github.com/nhsuk/manage-vaccinations-in-schools/releases/)
43
-
using this tag, or if one has been created for this version already update the
44
-
tag in it. The assurance statement will also need to be updated with the tag URL
45
-
(if the tag changes, e.g. to `-rc2`, this will need to be updated).
46
-
47
-
At this point the changes in the release will go through the NHS assurance
48
-
processes, and possibly through external testing and assurance. If required it
49
-
can be deployed to the `preview` or `training` environements.
50
-
51
-
## Deploy to production
52
-
53
-
When we are ready to release, update the `release` branch and deploy it to
54
-
production. If there have been no hot-fixes since the last release then this is
55
-
a simple fast-forward merge that has to be done on your localhost (see below for
56
-
how to manage non-fast-forwardable situations):
10
+
The `release` branch is a reference to what is in production at any point in
11
+
time and updated at the time the release is performed. It usually tracks `main`
12
+
but can also point to hotfix branches as necessary.
13
+
14
+
Releasing follows these steps, performed once approval for release has been
15
+
given:
16
+
17
+
1. Create a PR to merge `next` into `main`; approve and merge.
18
+
2. Create a draft release by running the `Draft new release` workflow. This
19
+
creates a draft release in GitHub with initial release notes.
20
+
3. Update the release notes with information about the changes. This is
21
+
generated from the Jira tickets by a team member.
22
+
4. Publish the release in GitHub. This will create the tag.
23
+
5. Check the notes for pre and post-release tasks and ensure these are performed
24
+
before and after releasing to the environments below.
25
+
6. Deploy the release to the `preview` and `training` envs, if not already done.
26
+
This can be used as a test that the tag deploys as expected.
27
+
7. If there are migrations that need testing (e.g. a data migration or a
28
+
long-running migration), deploy this release to `data-replication` and test
29
+
the performance of the migration(s) there.
30
+
8. Perform pre-release tasks.
31
+
9. Run the `Deploy` workflow to deploy to production.
32
+
10. Smoke test: login to the production service to ensure it looks normal.
33
+
11. Perform post-release tasks.
34
+
12. Fast-forward or reset `release` to the release tag.
35
+
13. Update the service management channel on NHSE Slack.
36
+
14. Update the topic in the Mavis tech channel to reflect the new version.
37
+
38
+
Additional notes below.
39
+
40
+
## Running the Deploy workflow
41
+
42
+
Use the `deploy.yml` workflow to run the deployments. For the production
43
+
deployment, it's important to start the workflow from the `main` branch and
44
+
specify the tag to deploy as input. This is because only workflows from the
45
+
`main` branch can authenticate with the production AWS account.
46
+
47
+
Changes to the backup infrastructure must be deployed separately. In the rare
48
+
case that the backup infrastructure needs to be updated, run the
49
+
`deploy-backup-infrastructure.yml` workflow.
50
+
51
+
## Upading the release branch
52
+
53
+
We update the `release` branch after we've deployed `main` to production. If
54
+
there have been no hot-fixes since the last release then this is a simple
55
+
fast-forward merge that has to be done on your localhost (see below for how to
56
+
manage non-fast-forwardable situations):
57
57
58
58
```shell
59
59
git checkout release
@@ -68,17 +68,7 @@ git merge --ff-only v1.0.0-rc1
68
68
git push --tags origin release
69
69
```
70
70
71
-
Once the `release` branch is updated on GitHub, create the release in GitHub UI
72
-
with the release tag, e.g. v1.0.0, moving the release notes from the release
73
-
candidate. Now it's time to deploy. Start with a deploy to `training` or
74
-
`preview` to ensure the tagged version is correct. Once that's done you can
75
-
deploy to production.
76
-
77
-
Use the `deploy.yml` workflow to run the deployments. For the production deployment, it's important to start the workflow from the `main` branch and specify the tag to deploy as input. This is because only workflows from the `main` branch can authenticate with the production AWS account.
78
-
79
-
Changes to the backup infrastructure must be deployed separately. In the rare case that the backup infrastructure needs to be updated, run the `deploy-backup-infrastructure.yml` workflow.
80
-
81
-
## When `release` and `main` have diverged
71
+
### When `release` and `main` have diverged
82
72
83
73
There are cases when `release` won't be fast-forwardable to the release
84
74
candidate on `main`. This will happen when a fix has been applied to the
@@ -136,6 +126,8 @@ previously described.
136
126
137
127
## Rollback
138
128
139
-
A release can be rolled back by deploying the previous release tag using the regular GitHub workflow. This can be done on a per-service level or for all services.
140
-
If the issue is spotted early and the CodeDeploy deployment is still in progress, the new deployment can still be aborted.
141
-
To do this, go to the CodeDeploy console, select the deployment group, and click "Stop deployment".
129
+
A release can be rolled back by deploying the previous release tag using the
130
+
regular GitHub workflow. This can be done on a per-service level or for all
131
+
services. If the issue is spotted early and the CodeDeploy deployment is still
132
+
in progress, the new deployment can still be aborted. To do this, go to the
133
+
CodeDeploy console, select the deployment group, and click "Stop deployment".
0 commit comments