Szczepan Faber I’m obsessed with quality I coached teams I preached at conferences I’m test driven Every test is neat and fast Coverage is 90%+ and I release every 2 years… WTF?

Evolution Continuous Delivery is a black belt in Continuous Integration C.D. is like C.I. evolved

Mindset not a tool C.I: keeps software ready for development and validation gives quick feedback about the correctness

C.D: keeps software ready for the release gives quick feedback about the business value

Principles

Every build is a release candidate Automate Have quality automated tests More info: read the book :) see Jez Humble’s videos on the web

Menu

How Mockito does it How Gradle does it How big and famous do it

2007/2008

beautiful tests

less brittleness

easy to write

test code is code proud of the code

Recipe

+

Mockito popularity 9th java library or maybe 4th?

Problem I’m obsessed with quality I coached teams I preached at conferences I’m test driven Every test is neat and fast Coverage is 90%+ and I release every 2 years… WTF?

Deliver!

Quality is irrelevant What matters is “quality delivered”

Mockito 1.9.*

time consuming release notes creation rare releases release fear demotivating growing backlog concerned community

Mockito 1.10.*

●  time consuming release notes creation ●  rare releases ●  release fear ●  demotivating growing backlog ●  concerned community Challenges: ●  automation ●  quality assurance

Mockito’s model

push == new version (not snapshot) release notes and docs release notes automated can release from a phone ~10 minutes new energy

Tools

Integration

Travis CI and GitHub (via Gradle)

Travis CI can read and write to GitHub OAuth2 protocol Travis CI environment variables encryption GitHub REST API

Travis CI and Bintray

Bintray and jcenter Gradle Bintray plugin Bintray REST API

http://blog.bintray.com

Continuous Delivery

Releasing is fun instead of a chore Working on a feature or a bug is exciting Releasing is part of regular routine “Make releasing boring. No more adrenaline.” ~Jezz Humble

Mockito’s continuous delivery model wound’t be possible without...

Gradle’s release model

Release every ~2 months Major version release every 1-2 years Nightly builds Lots of automated validation Very credible tests

Challenges

Fast full feedback cycle from automated checks Huge amounts of automated tests Cross-platform testing Automated performance tests Flaky tests Culprit detection

Patterns

Flaky tests

What can we do about flaky tests? Flaky tests are a part the world Understand them. Model them. Automate them. Eliminate the the expensive flaky tests regularly.

Test selection

Do I need to invoke all available tests to validate my change?

Dry-running a change

How can I ensure that my change does not break the build?

Culprit detection

How to track down a test failure to a commit?

What is the “last known good” version?

Good version

Enterprise dependencies

Does my change breaks components that depend on me?

Perceptual diffs

“The Secret to Safe Continuous Deployment” ~Google developers

Thanks! Continous Delivery is a mindset Start slowly and incrementally Automate more Code is worth zero until released

Szczepan Faber Engineer, coach, consultant

@szczepiq