From 4119d24149afeef8c10781a744e416096c12eaac Mon Sep 17 00:00:00 2001 From: Alysia Broddrick Date: Thu, 2 Nov 2023 19:24:47 -0700 Subject: [PATCH] added documentation and ADR for release schedule --- .../0024-production-release-cadence.md | 28 +++++++++++++++++++ docs/operations/README.md | 6 ++++ 2 files changed, 34 insertions(+) create mode 100644 docs/architecture/decisions/0024-production-release-cadence.md diff --git a/docs/architecture/decisions/0024-production-release-cadence.md b/docs/architecture/decisions/0024-production-release-cadence.md new file mode 100644 index 000000000..7b5383068 --- /dev/null +++ b/docs/architecture/decisions/0024-production-release-cadence.md @@ -0,0 +1,28 @@ +# 19. Role-based Access Control + +Date: 2023-11-02 + +## Status + +In Review + +## Context + +Going into our first production launch we need a plan describing what our release cadence for both our staging and stable envirornment will be. Currently, we release to staging whenever there are significant changes made, but we have not been making releases to stable with the same frequency. When deciding what our release schedule would be, we discussed releasing to stable once a sprint compared to releasing once a week. + +## Considered Options + +**Option 1:** Releasing to stable/staging once a sprint +Releasing once a sprint would mean that we release the past sprint's work to stable at the end of the current sprint. At the same point, the current sprint's work would be pushed to staging; thus making staging a full sprint ahead of stable. While this is more straight forward, it means our users would have to wait longer to see changes that weren't deemed critical. +**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 staging only one week behind stable 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. Further, critical bugs or features would be exempt from these restrictions based on CISA's discretion. + +## Decision + +We decided to go with option 2 and release once a week once in production. This will allow us to give users features and bug fixes faster while still allowing enough time on staging for quality to be maintained. + +## Consequences + +Work not completed by end of the sprint will have to wait to be added to stable. \ No newline at end of file diff --git a/docs/operations/README.md b/docs/operations/README.md index 4de866cf5..176050ccc 100644 --- a/docs/operations/README.md +++ b/docs/operations/README.md @@ -43,6 +43,12 @@ For ease of use, you can run the `deploy.sh ` script in the `/src` Your sandbox space should've been setup as part of the onboarding process. If this was not the case, please have an admin follow the instructions [here](../../.github/ISSUE_TEMPLATE/developer-onboarding.md#setting-up-developer-sandbox). +## Rules for making Stable and Staging Releases + +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 excpetion of the first time going into production (see below), 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. + +If a bug fix needs to be made to stable, the code fix branch will need to be branched NOT off of main, but of of the same commit as the most recent stable commit. Then, after PR review, the code will be merged to main and a new release must be made to stable. + ## Serving static assets We are using [WhiteNoise](http://whitenoise.evans.io/en/stable/index.html) plugin to serve our static assets on cloud.gov. This plugin is added to the `MIDDLEWARE` list in our apps `settings.py`.