darkhelm/notifications-api
1
0
Fork 0
mirror of https://github.com/GSA/notifications-api.git synced 2026-02-05 02:41:14 -05:00
Code Issues Packages Projects Releases Wiki Activity

Create demo deploy workflows

Browse Source
This commit is contained in:
Ryan Ahearn
2022-11-02 09:55:56 -04:00
parent fe66ed2095
commit afd855442b
6 changed files with 169 additions and 17 deletions
Download Patch File Download Diff File Expand all files Collapse all files

14
docs/deploying.md
View File

@@ -1,18 +1,22 @@
# Deploying
We deploy automatically to cloud.gov for production and staging environments.
We deploy automatically to cloud.gov for demo and staging environments.
Deployment runs via the [deployment action](../.github/workflows/deploy.yml) on GitHub, which pulls credentials from GitHub's secrets store.
Deployment to staging runs via the [base deployment action](../.github/workflows/deploy.yml) on GitHub, which pulls credentials from GitHub's secrets store in the staging environment.
Deployment to demo runs via the [demo deployment action](../.github/workflows/deploy-demo.yml) on GitHub, which pulls credentials from GitHub's secrets store in the demo environment.
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
- Staging, which deploys from `main`
- Demo, which deploys from `production`
In the future, we will add a Production deploy environment, which will deploy in parallel to Demo.
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.
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.