Continuous Delivery Overview

Mockito champions true continuous delivery in the Open Source.

• Introduction
• Why?
• Why not?
• Details

## Introduction

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?

###Why?

• 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. Releases are very sustainable ensuring continual improvement of software. 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 changes, delaying the release to our users.
• 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.

###Why not?

Continuous delivery model introduces risks and problems.

• Prolonged beta phase of 2.x introduced chaos (we will never do it again!).
• Every contribution needs to be highest quality, what if a bug slips in despite rigorous QA and great test coverage?
• Users upset with too many versions available, which one to use? Reduced incentive to use latest version.
• 3rd party tools like versioneye report Mockito dependencies outdated too often, reducing incentive to update to latest.
• 3rd party tools that integrate with Mockito (like spring boot) do not know what is the best Mockito version to use.

See also great discussion in our issue tracker.

## Details

The details of the continuous delivery pipeline, including the historical background, are described in Continuous Delivery Details.