Release Strategies and Versioning
The important idea here is that; separating them ensures that can happen in a that facilitate .
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.
- Dark launching
- Feature toggles
- Blue/green deployment
- Canary releases
- A/B Testing