zydronium/manage.get.gov
1
0
Fork 0
mirror of https://github.com/cisagov/manage.get.gov.git synced 2025-07-23 03:06:01 +02:00
Code Issues Projects Releases Packages Wiki Activity

updated with feedback

Browse source
This commit is contained in:
Alysia Broddrick 2023-11-06 09:15:05 -08:00
parent 9725788a8b
commit ea26f0b1b5
No known key found for this signature in database
GPG key ID: 03917052CD0F06B7
2 changed files with 13 additions and 4 deletions
Download patch file Download diff file Expand all files Collapse all files

6
docs/architecture/decisions/0024-production-release-cadence.md
View file

@ -1,4 +1,4 @@
# 24. Role-based Access Control
# 24. Production Release Cadence
Date: 2023-11-02
@ -17,7 +17,7 @@ Releasing once a sprint would mean that we release the past sprint's work to sta
**Option 2:** Releasing to stable/staging once a week
Releasing once a week would follow the same flow but with code being released to staging one week before the same code is released to stable. This would make stable only one week behind staging and would allow us to roll out minor bug fixes and faster with greater speed. The negative side is that we have less time to see if errors occur on staging
In both of the above scenarios the release date would fall on the same day of the week that the sprint starts, which is currently a Wednesday. Additionally, in both scenarios the release commits would eventually be tagged with both a staging and stable tag. Furthermore, critical bugs or features would be exempt from these restrictions based on CISA's discretion.
In both of the above scenarios the release date would fall on the same day of the week that the sprint starts, which is currently a Wednesday. Additionally, in both scenarios the release commits would eventually be tagged with both a staging and stable tag. Furthermore, critical bugs or features would be exempt from these restrictions based on the product owner's discretion.
## Decision
@ -25,6 +25,6 @@ We decided to go with option 2 and release once a week once in production. This
## Consequences
Work not completed by end of the sprint will have to wait to be added to stable. Also, making hit fixes for bugs that are found on stable will be a little more complicated to fix.
Work not completed by end of the sprint will have to wait to be added to stable. Also, making quick fixes for bugs that are found on stable will be a little more complicated to fix.
When first going into production, staging and stable will start with the same code base. The following week a new release will be made to staging, but not stable as no code will have been on staging long enough to warrant another release. Thus just at the start of launch stable will be essentially frozen for 2 weeks, not one.