Add new infra processes

Author: lindenmckenzie

guides/CONTRIBUTING.md

@@ -2,34 +2,40 @@
 
 ## Development work
 
-* As a first step, GPG key setup is required in order to contribute:
+We currently have two different processes in place as we are transitioning between them.
+
+The below is true for both approaches, see branching strategy below for the differences.
+
+- As a first step, GPG key setup is required in order to contribute:
   instructions on setup can be found in the [GPG Guide](https://github.com/ONSdigital/dp-operations/blob/main/guides/gpg.md)
-* We use [git-flow](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow) -
-  create a feature or fix branch from `develop`, e.g. `feature/<new-feature>`, `fix/<new-fix>`. Alternatively, create a hotfix branch from master e.g. `hot-fix/<new-hotfix>`.
-* Pull requests must use the pull request template found in each repo. Each section must contain the following:
-  * 'What' - a succinct, clear summary of what the user-need is that is driving this feature change,
-  * 'How to review' - a step-by-step guide or set of guides that detail how a reviewer can test and verify the changes made
-  * 'Who can review' - a list of the most appropriate people to review the pull request,
+- Pull requests must use the pull request template found in each repo. Each section must contain the following:
+  - 'What' - a succinct, clear summary of what the user-need is that is driving this feature change,
+  - 'How to review' - a step-by-step guide or set of guides that detail how a reviewer can test and verify the changes made
+  - 'Who can review' - a list of the most appropriate people to review the pull request,
     e.g. if on a frontend application, a member of the frontend team should review; likewise for backend and platform.
     If the changes are critical or are likely to have severe side-effects then the Tech Lead should review.
-* Ensure your branch contains logical atomic commits before sending a pull request - follow the [GDS Way styleguide](https://gds-way.digital.cabinet-office.gov.uk/standards/source-code/working-with-git.html#commits)
-* You may rebase your branch after feedback if it's to include relevant updates from the `develop` branch. We prefer a rebase here to a merge commit as we
-  prefer a clean and straight history on the `develop` branch, with discrete merge commits for features
-* It is advised to squash commits before pushing to a remote repository
+- Ensure your branch contains logical atomic commits before sending a pull request - follow the [GDS Way styleguide](https://gds-way.digital.cabinet-office.gov.uk/standards/source-code/working-with-git.html#commits)
+- You may rebase your branch after feedback if it's to include relevant updates from the upstream branch. We prefer a rebase here to a merge commit as we
+  prefer a clean and straight history on protected branches, with discrete merge commits for features
+- It is advised to squash commits before pushing to a remote repository
 
-----
+### New branching strategy
 
-## Releasing
+We use trunk based development - create a feature branch from `main`, e.g. `feature/new-feature`
 
-* For instructions on how to release work, read the [Releases guidelines](RELEASES.md)
+### Old branching strategy
+
+We use [git-flow](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow) - create a feature or fix branch from `develop`, e.g. `feature/<new-feature>`, `fix/<new-fix>`. Alternatively, create a hotfix branch from master e.g. `hot-fix/<new-hotfix>`.
+
+## Releasing
 
-----
+For instructions on how to release work, read the [Releases guidelines](RELEASES.md)
 
 ## Access to Environments
 
 ### Note: if you get a 404 error for any of the below links, then you need to be added to the `ONSdigital` organisation in GitHub
 
-* For direct access to the environments
-  * Setup your [AWS credentials](AWS_CREDENTIALS.md)
-  * Configure your [SSH access](https://github.com/ONSdigital/dp-operations/blob/main/guides/ssh-access.md)
-  * [Ansible](https://github.com/ONSdigital/dp-ci/tree/master/ansible#prerequisites) is required for provisioning to environments
+- For direct access to the environments
+  - Setup your [AWS credentials](AWS_CREDENTIALS.md)
+  - Configure your [SSH access](https://github.com/ONSdigital/dp-operations/blob/main/guides/ssh-access.md)
+  - [Ansible](https://github.com/ONSdigital/dp-ci/tree/master/ansible#prerequisites) is required for provisioning to environments

guides/INSTALLING.md

@@ -212,7 +212,7 @@ Variable name | note
 --- | ---
 `zebedee_root` | path to your zebedee content, typically the directory the [dp-zebedee-content](https://github.com/ONSdigital/dp-zebedee-content) generation script points to when run
 `ENABLE_PRIVATE_ENDPOINTS` | set `true` when running services in publishing, unset for web mode
-`ENABLE_PERMISSIONS_AUTH`| set `true` to ensure that calls to APIs are from registered services or users
+`ENABLE_PERMISSIONS_AUTH` | set `true` to ensure that calls to APIs are from registered services or users
 `ENCRYPTION_DISABLED` | set `true` to disable encryption, making data readable for any debugging purposes
 `DATASET_ROUTES_ENABLED` | `true` will enable the filterable dataset routes (the CMD journey) in some services
 `FORMAT_LOGGING` | if `true` then `zebedee` will format its logs