Update release process documentation

README.md

@@ -19,19 +19,42 @@ Shared modules used by various DfE services.
 
 The [Example Rails deployment](EXAMPLE.md) document outlines the minimum steps required to set up a Rails application deployed using AKS.
 
-## Release process
-### References
-We maintain 3 git references and promote new features between them:
-- All new features are immediately added to the `main` branch. Environments with lowest risk (like review apps) use this reference so new features are tested quickly, errors are caught earlier and bugs have minimal impact.
-- A *pre-release* containing the new features from the past week (if there were any) is generated every week. It automatically updates the `testing` tag. Environments with low risk (like development or QA) use this reference so errors are caught in production like environments and bugs have low impact.
-- A *release* containing the features which were in testing the week before is created at the same time. It automatically updates the `stable` tag. Environments with higher risk (like production or preproduction) use this reference so only features which were thoroughly tested are deployed.
-
-### Process
-Given the `stable` tag points to tag `v0.x.0` and `testing` points to `v0.y.0`. To promote `v0.y.0` to stable:
-- Delete the current pre-release pointing to `v0.y.0`
-- Create a new release with tag `v0.y.0`, target testing and generate changelog `v0.y.0 ... v0.x.0`
-- If there are new commits in `main` that we want to promote to `testing`: increment `v0.y.0` to `v0.z.0`, then create a new pre-release with new tag `v0.z.0`, target main and generate changelog `v0.z.0 ... v0.y.0`. To create a pre-release, follow the steps:
-    > Select [Draft new release] -> Click [Choose a tag] -> Enter 'v0.z.0' -> Select [Create new tag] -> Select [Generate release notes] -> Select [Set as a pre-release] checkbox ->     Select [Publish release]
+## Release Process
+
+### Git References
+We use three git references to manage and promote new features:
+
+#### `main` branch
+All new features are added here first. This branch is used in environments with the lowest risk, such as review apps, to quickly test new features, catch errors early, and minimise the impact of bugs.
+
+#### `testing` tag
+A pre-release is generated every week that includes any new features in `main` from the past week. This tag is automatically updated and used in low-risk environments like development or QA. This allows us to catch errors in production-like environments and keep the impact of bugs low.
+
+#### `stable` tag
+A release is created that includes the features which were in the `testing` phase the previous week. This tag is automatically updated and used in higher-risk environments like production or preproduction. This ensures that only thoroughly tested features are deployed.
+
+### Promotion Process
+Let's assume the `stable` tag points to `v0.x.0` and `testing` points to `v0.y.0`. You can view the tags and their commit IDs [in the tags list](https://github.com/DFE-Digital/terraform-modules/tags).
+
+#### To promote `testing` to `stable`:
+1. Delete the current pre-release pointing to `v0.y.0`
+1. Create a new release:
+    - Select `Draft new release`
+    - Click `Choose a tag` and enter `v0.y.0`
+    - Select `Previous tag` `v0.x.0`
+    - Click `Generate release notes`
+    - Check the `Set as the latest release` box
+    - Click `Publish release`
+
+#### To promote new commits in `main` to `testing`:
+If there are new commits in `main` that you want to promote to `testing`, increment `v0.y.0` to `v0.z.0`, then create a new pre-release:
+1. Select `Draft new release`
+1. Click `Choose a tag` and enter `v0.z.0`
+1. Click `Create new tag`
+1. Select the `Previous tag` `v0.y.0`
+1. Click `Generate release notes`
+1. Check the `Set as a pre-release` box
+1. Click `Publish release`
 
 ## Updating [Terraform Docs]