docs: document how Digital Pooling services are deployed

Document how Digital Pooling follows the divisional deployment
boilerplate standard. Pipelines in service repos push images
to the meta Artifact Repository and pipelines in the deployment
project are responsible for running terraform plan & apply.

docs/services/digital-pooling.md

@@ -118,20 +118,32 @@ The SMI infrastucture is deployed using Terraform, with releases of the main app
 synchronisation job application deployed by the GitLab CD pipelines associated with the
 [infrastructure deployment repository](https://gitlab.developers.cam.ac.uk/uis/devops/digital-admissions/pools/deploy).
 
-### Deploying a new release
+### Deployments
 
-<!-- markdownlint-disable-next-line MD013 -->
-To deploy a new release, a new issue is created in the current sprint following [this template](https://gitlab.developers.cam.ac.uk/uis/devops/digital-admissions/pools/deploy/-/blob/master/.gitlab/issue_templates/release.md).
+Digital Pooling follows the divisional deployment boilerplate standard. Container images
+are pushed to the meta project's Artifact Registry as part of every pipeline on the SMI
+and Synchronisation Service repositories.
+
+The deployment repo ([pools/deploy](https://gitlab.developers.cam.ac.uk/uis/devops/digital-admissions/pools/deploy))
+is responsible for actually deploying services. The `development` & `staging` environments
+default to the 'latest' tag on the `master` branch, ie. the latest merged code.
+The `integration` & `production` environments have a specific tag (release) of the code
+deployed on them. Terraform locals are used to configure which version is deployed to a
+given environment.
 
-### Deployment schedule
+Pipelines in the deployment repo run `terraform plan` for all environments. The job to
+run `terraform apply` is always enabled on pipelines for the `master` branch. For all
+other environments, the `apply` job being available is contingent on the `plan` job
+succeeding.
 
-All environments are deployed to at sprint end.
-However, there are some exceptions:
+The `terraform plan` job will need re-running for a given environment if the output of
+this becomes stale (because the environment state changes) before `terraform apply` can
+be run.
 
-- Development is only deployed to at sprint end, to keep it up to date, if there is no one currently
-  using it for feature testing. This manual feature testing deployments are only done when a larger
-  piece of functionality needs further testing, after manual development before or during a review.
-- Staging is deployed to on merge to master.
+### Deploying a new release
+
+<!-- markdownlint-disable-next-line MD013 -->
+To deploy a new release, a new issue is created in the current sprint following [this template](https://gitlab.developers.cam.ac.uk/uis/devops/digital-admissions/pools/deploy/-/blob/master/.gitlab/issue_templates/release.md).
 
 ### User access management