fixup! Update deployment documentation

doc/deployment-process.md

@@ -7,6 +7,13 @@ Deployments are made from AWS via CodePipelines.
 To view deployments or trigger them, you will need access to the hosting, see
 the [hosting documentation](/doc/hosting.md) for more information.
 
+**IMPORTANT**: The CodePipelines are polling-based. If a pipeline has not run in over
+30 days, AWS will turn it off, and a developer will have to [trigger a
+release](#monitor-or-trigger-deployments) manually.
+
+**NOTE**: There is no indication in Github what branch is deployed where, the
+only way to find out is via the CodePipelines in AWS.
+
 ## Environments
 
 Merges into the `develop` branch will deploy the changes to:
@@ -19,11 +26,33 @@ Merging into the `main` branch will deploy the changes to:
 - training
 - production
 
-**NOTE**: The AWS pipelines are polling-based. If a pipeline has not run in over
-30 days, AWS will turn it off, and a developer will have to log in and restart
-deployments manually, by using "Release change".
 
-## Process
+## Monitor or trigger deployments
+
+To monitor deployments follow these steps:
+
+- sign in to AWS with your `digital-paas-production-account` account
+- assume the role for the appropriate environment, see [hosting
+  documentation](/doc/hosting.md#assuming-roles)
+- Locate _CodePipelines_ in the services menu
+- Click on the name of the Pipeline
+
+You will see the three stages of deployment: Source, Build and Deploy. You can
+view details of each stage.
+
+To trigger a deployment:
+
+- sign in to AWS with your `digital-paas-production-account` account
+- assume the role for the appropriate environment, see [hosting
+  documentation](/doc/hosting.md#assuming-roles)
+- Locate _CodePipelines_ in the services menu
+- Click on the name of the Pipeline
+- Click on the _Release changes_ button, top right
+
+The tip of the branch will be deployed, see [environments](#environments)
+
+
+## Deployment process
 
 Production deploys are done by manually merging develop into main. To give us a
 slightly more formal process around what gets deployed and when and also to give
@@ -43,11 +72,15 @@ the differences between the current release and the previous one. For example:
 ### Example
 
 ```
-## [release-1]
+## Release-1 - 2024-01-01
+
+[Full changelog][1]
+
 - A change
 - Another change
 
-[release-1]: https://github.com/UKGovernmentBEIS/beis-report-official-development-assistance/compare/release-1...release-0
+[unreleased]: https://github.com/UKGovernmentBEIS/beis-report-official-development-assistance/compare/release-1...HEAD
+[1]: https://github.com/UKGovernmentBEIS/beis-report-official-development-assistance/compare/release-0...release-1
 ```
 
 ### Steps
@@ -66,29 +99,46 @@ the differences between the current release and the previous one. For example:
      - document the changes in this release in a bullet point form
      - add a link to the diff at the bottom of the file
    - Copy the list of changes from the changelog into the commit message
-   - Push the changes up to Github ``` git push -u origin release-X # e.g. git
-     push -u origin release-120 ````
-   - Create a pull request to merge that release into **develop** with content
+   - Push the changes up to Github 
+        ```
+        git push -u origin release-X # e.g. git
+        push -u origin release-120 
+        ```
+   - Create a pull request to merge that release into _develop_ with content
      from the CHANGELOG.md
 1. Get that pull request reviewed and merged
    - Confirm that the changes in the release are safe to ship and that
      CHANGELOG.md accurately reflects the changes included in the release.
    - Merge the pull request
-1. Update your local develop branch and tag the merge commit on develop ``` git
-tag release-X [merge-commit-for-release] # e.g. `git tag release-120
-e1156bfd2cf45a0281808edb8342055407c0f253` ```
+1. Update your local develop branch and tag the merge commit on develop 
+        ``` 
+        git tag release-X [merge-commit-for-release]
+        ```
 1. Push the tag to Github (we need the refs otherwise git will not know if you
-mean the tag or the branch as they have the same name)   ``` git push origin
-refs/tags/release-X # e.g. `git push origin refs/tags/release-120` ```
+mean the tag or the branch as they have the same name)   
+        ``` 
+        git push --tags
+        ```
+1. Create a Github release
+    - Click on Releases
+    - Click on Draft new release
+    - Choose the release tag
+    - Set the release title to 'Release-x'
+    - Set the body of the release to list of changes for the release, copy them
+      from the CHANGELOG.md
+    - Click on Publish release
 1. Announce the release Let the team know about the release. This is posted in
-Slack under #beis-roda. Typical form is: ``` @here :badgerbadger: Release N of
-RODA going to production :badgerbadger: ```
+Slack under #beis-roda, link to the release notes.
 1. Manually merge develop into main in order to release
    - Once the release pull request has been merged into the develop branch, the
      production deploy can be performed by manually merging develop into main:
-     ``` git fetch git checkout main git pull git merge origin/develop # Edit
-     the commit message to reference the release number # e.g. "Release 43" or
-     "merge origin/develop for release 43" git push ```
+        ```
+        git fetch 
+        git checkout main 
+        git pull 
+        git merge origin/develop
+        ```
+    - Set the merge commit title to 'Release-x'
 1. Production smoke test once the code has been deployed to production, carry
 out a quick smoke test to confirm that the changes have been successfully
 deployed.