zydronium/manage.get.gov
1
0
Fork 0
mirror of https://github.com/cisagov/manage.get.gov.git synced 2025-08-04 08:52:16 +02:00
Code Issues Projects Releases Packages Wiki Activity

Merge pull request #1597 from cisagov/release-cadence-update

Browse source 
updated release cadence document
This commit is contained in:
Alysia Broddrick 2024-01-09 19:43:33 -08:00 • committed by GitHub
commit 124b3e21cb
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 1 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

2
docs/operations/README.md
View file

@ -83,7 +83,7 @@ If we ever need a new environment to replace `development`, `staging` or `stable
## Stable and Staging Release Rules
Releases will be made for staging and stable every week starting on the first day of the sprint (Wednesday), with the second release of the sprint occuring halfway through the sprint. With the exception of first time going into production, these releases will NOT have the same code. The release to stable will be the same commit that was tagged for staging one week prior, making stable one week behind staging. Further, this means staging can be up to a week behind the main branch of code.
Releases will be made for staging and stable twice a week, ideally Tuesday and Thursday, but can be adjusted if needed. Code on `main` will be released to `staging`, and then on the following Tuesday/Thursday this `staging` release will become the new `stable` release. This means every release day, a release will be made to `stable` containing the last `staging` code. On this same day a new `staging` release will be made that contains the most up-to-date code on main. Thus, `staging` can be a few days behind the main branch, and `stable` will be a few days behind the code on `staging`.
If a bug fix or feature needs to be made to stable out of the normal cycle, this can only be done at the product owner's request.