Brad Lucas

Programming, Clojure and other interests
June 14, 2017

Release Procedures

Some Rules

  • 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

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


  • [ ] 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


Previously saved as a Gist

Tags: managing