This space is a repository for information about release strategy in complex software projects. It was initiated by 
Niklas Bjørnerstedt and Johannes Brodwall. They plan for the information here to be structured into one or more publications. All submissions should be considered licensed under a Creative Commons Attribution 3.0 license
.
This wiki is still in the early stages of development. Many of the pages are unfinished.
Intro
How long did it take before your last project was able to put a first version into production? How long was the release cycle after that? The basic premise of this wiki is that any project that is not able to release to production at least once every three months has a problem. The longer the release cycle the bigger the risk of partial or complete failure. The product owner should actively work towards reducing the length of releases. It will not always be possible to release every three months but it should always be the goal a project strives after. Once a system is in production most projects should be able to release at the end of every iteration.
The idea of releasing often is not new. Most agile approaches recommend frequent releases. What is unique with this wiki is that it is a repository of concrete advice on how to actually reduce the size of releases and find a project's Minimal Releasable Product.
Why release often?
The advantages of releasing often
Arguments against releasing often
Common Arguments against releasing often
Patterns
Patterns that you can use to find an optimal MRP... and some Antipatterns
Techniques
Techniques that can be used to work with releases.
Recently Updated
|
Navigate space |
