fixup! CLDC-NONE: Document release process

move this to the existing infrastructure section

docs/adr/index.md

@@ -1,6 +1,6 @@
 ---
 has_children: true
-nav_order: 14
+nav_order: 13
 ---
 
 # Architecture decisions

docs/app_api.md

@@ -1,5 +1,5 @@
 ---
-nav_order: 9
+nav_order: 8
 ---
 
 # Using the App API

docs/bulk_upload.md

@@ -1,5 +1,5 @@
 ---
-nav_order: 13
+nav_order: 11
 ---
 
 # Bulk Upload

docs/csv_downloads.md

@@ -1,5 +1,5 @@
 ---
-nav_order: 11
+nav_order: 10
 ---
 
 # CSV Downloads

docs/documentation_website.md

@@ -1,5 +1,5 @@
 ---
-nav_order: 15
+nav_order: 14
 ---
 
 # This documentation website

docs/exports.md

@@ -1,5 +1,5 @@
 ---
-nav_order: 8
+nav_order: 7
 ---
 
 # Exporting to CDS

docs/form/index.md

@@ -1,6 +1,6 @@
 ---
 has_children: true
-nav_order: 10
+nav_order: 9
 ---
 
 # Generating forms

docs/infrastructure.md

@@ -57,7 +57,7 @@ Where to find the Infrastructure?
 The infrastructure is managed as code.
 In the terraform folder of the codebase, there will be dedicated sub-folders for each of the aforementioned environments, where all the infrastructure for them is defined.
 
-## Deployment (Pipeline — Recommended)
+## Production Deployment
 
 The application is set up so that it can be deployed via GitHub actions. We use Git tags to mark releases. The only pre-requisite is that your GitHub account is added to our team.
 
@@ -66,12 +66,13 @@ To deploy you need to:
 1. Determine [previous version](https://github.com/communitiesuk/submit-social-housing-lettings-and-sales-data/tags), such as `v0.1.1`.
 2. Create a [new release](https://github.com/communitiesuk/submit-social-housing-lettings-and-sales-data/releases/new) with subsequent version (e.g., `v0.1.2`). On this page, create a new tag with that version and generate release notes. Save as draft.
 3. Post release notes on Slack.
-4. Publish release.
-5. Monitor alerting, logging and Sentry.
-6. Post success message on Slack.
-7. Tag tickets as ‘Released’ and move tickets to done on JIRA.
+4. Ensure that there are no other pipelines running on the repo right now. If a staging deployment is running, it must complete before you can deploy to production.
+5. Publish release. This will trigger the deployment pipeline.
+6. Monitor alerting, logging and Sentry.
+7. Post success message on Slack.
+8. Tag tickets as ‘Released’ and move tickets to done on JIRA.
 
-## CI/CD
+## Staging Deployment
 
 When a commit is made to `main` the following GitHub action jobs are triggered:
 

docs/monitoring.md

@@ -1,5 +1,5 @@
 ---
-nav_order: 7
+nav_order: 6
 ---
 
 # Logs and Debugging

docs/rake.md

@@ -1,5 +1,5 @@
 ---
-nav_order: 12
+nav_order: 11
 ---
 
 # Running Rake Tasks

docs/release.md

@@ -1,30 +0,0 @@
----
-nav_order: 6
----
-
-# Releasing CORE code
-
-Getting code released on core has the following steps.
-
-## Releasing to staging
-
-Merging a branch to `main` will trigger the staging deployment pipeline.
-
-## Releasing to prod
-
-This is managed through GitHub releases
-
-### Creating a draft release
-
-In the GitHub releases section, create a new release. Release notes can be auto generated. All new commits on main since last release will be released.
-
-Create a new version tag with an incremented version number.
-
-Be sure to save the release as a draft until it is ready to be deployed.
-
-### Publish
-
-Publishing the release will deploy to prod.
-
-The release action copies the current staging images to prod. Ensure that when publishing the release, the last **staging deployment pipeline** has completed successfully.
-Else, changes will not be deployed as expected.