more ci info

README.md

@@ -31,6 +31,7 @@ Our other repositories are:
 
 - [Local setup](#local-setup)
 - [Testing](./docs/testing.md)
+- [Deploying](./docs/deploying.md)
 - [Running one-off tasks](./docs/one-off-tasks.md)
 
 ## UK docs that may still be helpful

docs/deploying.md

@@ -0,0 +1,18 @@
+# Deploying
+
+We deploy automatically to cloud.gov for production and staging environments.
+
+Deployment runs via the [deployment action](../.github/workflows/deploy.yml) on GitHub, which pulls credentials from GitHub's secrets store.
+
+The [action that we use](https://github.com/18F/cg-deploy-action) deploys using [a rolling strategy](https://docs.cloudfoundry.org/devguide/deploy-apps/rolling-deploy.html), so all deployments should have zero downtime.
+
+The API has 2 deployment environments:
+
+- Production, which deploys from `main`
+- Staging, which does not, in fact, exist
+
+Configurations for these are located in [the `deploy-config` folder](../deploy-config/).
+
+In the event that a deployment includes a Terraform change, that change will run before any code is deployed to the environment. Each environment has its own Terraform GitHub Action to handle that change.
+
+Failures in any of these GitHub workflows will be surfaced in the Pull Request related to the code change, and in the case of `checks.yml` actively prevent the PR from being merged. Failure in the Terraform workflow will not actively prevent the PR from being merged, but reviewers should not approve a PR with a failing terraform plan.

docs/testing.md

@@ -21,6 +21,8 @@ On GitHub, in addition to these tests, we run:
 
 We're using GitHub Actions. See [/.github](../.github/) for the configuration.
 
+In addition to commit-triggered scans, the `daily_checks.yml` workflow runs the relevant dependency audits, static scan, and/or dynamic scans at 10am UTC each day. Developers will be notified of failures in daily scans by GitHub notifications.
+
 ## To run a local OWASP scan
 
 1. Run `make run-flask` from within the dev container.