-
No releases after hours unless previously negotiated
-
Reponsible parties need to be present during the release
- ie, Developer and Ops
-
Different systems have different release requirements
- All have dependencies
- Need to know roll back procedure
- And, how to know if a roll back is necessary
-
The release may have `other` tasks. These should be documented and have been previously tested
- Any env settings, configuration setting changes
- Database changes
- Systems that need to be stopped and started as part of the release
- The `recipe` should be published
- The `recipe` should have been followed in a `testing/staging` environment
-
Use Git Flow
-
Releases are from release/VERSION_NUMBER branches
-
All code should be reviewed if necessary and merged to `develop` prior to release
- ie, releases are branched from a stable state
-
Releases are numbered with a x.x.x format
- Each release should increment intelligently
- If any confusion get it sorted out ahead of time
-
DevOps will deploy the branch unless previously negotiated
- All features have been merged back into develop
- Merging can be done using Pull Requests for secondary approval
- All features have been tested in a Test environment
- Tests can be done off origin/feature/my-new-feature
- or if a final feature form a set of features origin/develop
- A release branch has been created with the new version number
- Release branch is pushed to it's remote origin/release/VERSION_NUMBER
- All involved know of the schedule release time
- Ops sets a time agreeable to all
- Developer will be present or reachable at said time
- A rollback procedure has been defined
- All dependent changes have been documented. The `recipe` has been published