Date: 2021-01-27 (Updated 2022-07-18)
Accepted
Our Cloud.gov organization currently has three Spaces -- tanf-dev
, tanf-staging
, and tanf-prod
. The vendor team currently has access to the tanf-dev space only.
Since the recent changes to our Git workflow we believe our current deploy strategy should be updated to more closely match the workflow. Previously, since we had approvals on two different repositories we decided that it made sense to maintain two separate staging sites. We would deploy to one with approval in the raft-tech repository, and another with approval to HHS. Since we now have all approvals made in raft-tech, the deploy after approval serves the same purpose as deploying to the Government staging site would have.
Additionally, as of January 2021, the project has only a single deployment environment in the tanf-dev
space on Cloud.gov. This poses challenges to the vendor development team. The team works on multiple features or fixes at any one time, but only has a single environment to test deployed code. This is leading to "crowding", where multiple in-progress features by different devs all want to be deployed to the same environment for testing.
As of Spring 2022, following ADR 018, the project needs more than one deployment environment in the tanf-staging
space on Cloud.gov to ensure that there is a dedicated environment for release-specific features.
Deploy Environment | Cloud.gov Space | Cloud.gov Dev Access | Role | Deploys when ... |
---|---|---|---|---|
Dev | Tanf-Dev | Vendor & Gov | Deploy code submitted for gov review | Relevant github label assigned as shown below |
Develop | Tanf-Staging | Vendor & Gov | Deploy code once gov-approved | Code merged to raft-tech/TANF-app:develop |
Staging | Tanf-Staging | Gov | Deploy code once gov-approved | Code merged to HHS/TANF-app:main |
Production | Tanf-Prod | Gov | Deploy code tested in staging & ready for prod | Code merged to HHS/TANF-app:master |
We will be following the Gitflow process which is an industry standard. You can read more about it in our ADR. I will just highlight the parts relevant for our deployment strategy. Release branches will be merged to HHS/TANF-app:master
which will deploy to our production sites. Code merged to raft-tech/TANF-app:develop
will be deployed to our staging sites.
Within the dev space, there is no correlation for branch to environment as these feature or bugfix branches will constantly vary:
Dev Site | Frontend URL | Backend URL | Purpose |
---|---|---|---|
Sandbox | https://tdp-frontend-sandbox.app.cloud.gov | https://tdp-backend-sandbox.app.cloud.gov/admin/ | Space for development in a deployed environment |
A11y | https://tdp-frontend-a11y.app.cloud.gov | https://tdp-backend-a11y.app.cloud.gov/admin/ | Space for accessibility testing |
QASP | https://tdp-frontend-qasp.app.cloud.gov | https://tdp-backend-qasp.app.cloud.gov/admin/ | Space for QASP review |
raft | https://tdp-frontend-raft.app.cloud.gov | https://tdp-backend-raft.app.cloud.gov/admin/ | Space for Raft review |
Pros
- 3-space strategy instead of 4 aligns better with our current gitflow.
- Code deploys automatically upon gov approval, but does not deploy immediately to prod, leaving room for further gov testing. Any mistakes that make it past gov review will not deploy immediately to prod.
- Vendor dev team "crowding" should be reduced through this solution.
- Only need to maintain/monitor vendor dev access to a single Cloud.gov Space using this solution -- least privilege, simplified account management.
- Frees up memory and disk space in the dev environment.
- Dedicated environment for release-specific features.
Risks
- None that we can see at this time
- As of June 2022, CircleCI supplies environment variable key-value pairs to multiple environments (e.g. vendor's CircleCI deploys applications to dev and staging environments). The values from CircleCI are expected to be unique per environment, so until #1826 is researched and addressed, these values will need to be manually corrected in cloud.gov immediately following the execution of the execution of the
<env>-deployment
CircleCI workflow CircleCI workflow. This workaround applies to backend applications in the TDP staging environment.