Ready for continuous deployment?

Few weeks ago I've asked on Mockito dev list about the next release. I really like the idea of publishing every change that passes the build as a new version, available to everyone. Nobody really backed me up. Typically, if I have some idea, the more opposite recommendations I hear, the harder I want to get the idea implemented. That's just how my brain works, for good or bad. On the side note, I was surprised that Mockito devs were not excited about rolling out true continuous deployment. This got me thinking into why...

There was a point raised that applying continuous deployment will increase the risk that unstable versions are published to the community. Given the breadth of Mockito's automated test coverage we should not be afraid of this problem. After all, we will publish only when the build is happy with the change. BTW. This is already happening: every push to Mockito that Travis CI is happy with is published to bintray. It's not a snapshot: it's a new, specific version. The infrastructure is not entirely ready so the version contains '-dev' postifx. Soon it will be ready.

I cannot wait to get more progress on continuous deployment for Mockito. It's totally exciting to roll out this philosophy to a product that is very mature and contains large user base. Plus, Mockito hasn't got a release in a while. So it will be a leap jump from a slow release cadence into the new Era of Continuous Deployment. The challenge here is to roll it out without dropping the quality. We are TDD, we are semantic versioned, we are code quality junkies (this includes test code quality). Soon we'll be continuously deployed.

As we automate on, I will write more about challenges, ideas and tooling. I want to hear from you, too. I want to know how you do continuous deployment, about tools and patterns, about plans and the future. So far, my high level vision as of today (subject to change without notice) is:

• publishing high quality releases is completely effortless and happens automagically
• every change in the codebase matters and results in a new publication available to everybody (not snapshot)
• every change has the same (high) quality criteria, enforced by automated build
• commit messages _matter_ and enable automation of documentation and release notes
• every pull request that keeps the build green (blue?) is automatically published, along with documentation and release notes, with a distinct version number, available for immediate use by the PR author and everyone else in the world. Let's rock.

PS. I'm moving to the Silicon Valley in couple of months and I intend to automate everything that stands on my way :)