Release Strategies and Versioning

The important idea here is that Deploy is not Release; separating them ensures that Developing Good Explanations can happen in a Empowering Environments that facilitate Psychological Safety.

The general idea is to put things into place incrementally so that every individual step is functional on its own. Put code into production before actually releasing, essentially. Then you can smoke test the application, soak test the application, warm up caches, and do other preparation tasks.

  • Release Strategies can work with CI by employing a version-hash where the CI pipeline uses the version corresponding to the starting point and adds a hash. This allows for parallel “versionless” development that can be merged in however. Then, release tags can be made from a green master in accordance with the chosen release strategy.
  • If all changes come with sufficient Context (e.g. through a linked issue), it’s possible to automatically determine the appropriate version.

Yet another implementation of Branch By Abstraction.

  • Dark launching
  • Feature toggles
  • Blue/green deployment
  • Canary releases
  • A/B Testing
  • Versioning#