Some Rules
- No releases after hours unless previously negotiated
- Reponsible parties need to be present during the release
- 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
Source Control
- 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
Checklist
- [ ] 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
Reference
Previously saved as a Gist
https://gist.github.com/bradlucas/2536c5771bb08b7ad149