Continuous Delivery Overview
Mockito champions true continuous delivery in the Open Source. This page contains the overview of automated release model. For technical details see Continuous Delivery Details.
Mockito continuously delivers every change to production by publishing new version to central repository. This methodology is different than traditional release management, where features and bugfixes are accumulated before they get released. In traditional model, the release starts with “beta” or “release candidate” cycle to flesh out eventual bugs, followed by the release of a final version. Why does Mockito use continuous delivery model as opposed to traditional model?
- Productivity. Accumulating features without a release adds management overhead and release candidate cycle overhead. Time allocated to release management can be better spent on adding great features to Mockito that can delight our users.
- Sustainability. Fully automated releases ensure the project is alive. Open Source project is maintained by volunteers who may need to step out from project to catch up with life. This would potentially leave unfinished, unreleased changes. In continuous delivery unfinished changes don't exist.
- Efficiency. Practitioners of continuous delivery need to adopt higher degree of engineering discipline, making the team more efficient in general. Every change needs upfront quality assurance, technical concerns need to be resolved early, test coverage needs to be bullet proof, backwards compatibility and semantic versioning are a must. Every day. Efficient team delivers great features to users timely.
- Community. It is very engaging and attractive for contributors to be able to deliver a new feature or a bugfix, and have it immediately released to everybody. Of course the contribution must pass the quality criteria first.
- Innovation. Pioneering continuous delivery model for Java Open Source libraries is a tremendous opportunity to develop techniques, tools and accumulate knowledge (lessons learned). This is an important contribution to the software community.
See also Szczepan's short, highly opinionated article on continuous delivery VS traditional release model.
Continuous delivery model introduces concerns. Q&A:
Q: Prolonged beta phase of 2.x introduced too many beta versions. A: We will never do it again!
Q: Every contribution needs to be highest quality, what if a bug slips in despite rigorous QA and great test coverage? A: We put great deal of effort to ensure highest quality and compatibility. Bugs happen regardless of the release cadence, frequently releasing small changes helps ensuring quality.
Q: Users are upset with too many versions available, which one to use? There is a risk of reduced incentive to use latest version. A: The best version of Mockito is the latest version. We rigorously practice semantic versioning.
Q: 3rd party tools like versioneye report Mockito dependencies outdated too often, reducing incentive to update to latest. A: It would be great if versioneye worked better with libraries that adopted continuous delivery, such as Mockito.
Q: 3rd party tools that integrate with Mockito (like spring boot) do not know what is the best Mockito version to use. A: Use latest version (acknowledging that it would be easier for integrators if Mockito release cadence was more similar to theirs).
Q: Dependency management is harder because Mockito releases too often. A: Mockito fully embraces semantic versioning therefore it shouldn't introduce dependency management problems for clients.
See also great discussion in our issue tracker.
The details of the continuous delivery pipeline, including the historical background, are described in Continuous Delivery Details.