Brendan E. Quinn, Mount Watatic LTD

CONTINUOUS DELIVERY

WHAT IT ISN’TWHAT IT ISWHY IT MATTERS

About me

• Brendan Quinn, Mount Watatic LTD

• Been on the internet since 1987

• Working on the internet since 1993

• Worked as a developer, sysadmin, network engineer, security engineer, and architect

• Worked at places like Yahoo!, Betfair, Tufts University, and Digital Equipment Corporation

• Oh, and I’m a musician.

What CD isn’t:

• Continuous Delivery isn’t (only) Continuous Integration

• Continuous Delivery isn’t a set of tools.

• Continuous Delivery isn’t a planning system

• Continuous Delivery isn’t a collection of standards

• Continuous Delivery isn’t a magic bullet

What CD is:

• Continuous Delivery is an approach to developing software aimed at building, testing, and deploying software more frequently. Ideally every check in should generate a potential release.

• It’s also the title of an excellent book by Jez Humble and Dave Farley

Continuous Delivery

Principles

• Create a repeatable, reliable process for releasing software

• Automate (almost) everything• Keep everything in version control• If it hurts, do it more frequently, and bring

the pain forward• Build quality in• “Done” means “released”• Everybody is responsible for the delivery

process• Continuous Improvement

From “Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation”

An example CD pipeline

A Continuous Delivery pipeline is a path to production release, made up of multiple discrete phases.

Each post-build phase consists of automated

deployment of that build, and a test cycle, which may

be either automated or manual

Pipelines include every aspect of the software release cycle

• Since everything is in the pipeline, everything is repeatable

• Manual testing and approval phases are often necessary, and must be included in the pipeline

• Everyone (and I mean EVERYONE) has to be responsible for ensuring that the pipeline works

• Cross functional teams can help

• Never check-in against a broken pipeline unless it’s a fix!

Corollary #1

Faster feedback is betterThe quicker you know a build is broken, the faster you can fix it.

• Testing builds repeatedly, and deploying them each time also tests your deployment processes

• Manual, and long-running automated test phases should be late in the pipeline

• Use dashboards/information radiators to surface information on pipeline state quickly

Corollary #2

You have to trust your tests!Whatever your test regime, if you can’t trust the tests, you can’t release with confidence

Multiple phases allow the build to be tested in different ways. With some thought and attention, you can quickly become very confident in your builds.

Test Driven Everything

• If you can’t test it, you can’t be sure you’ve met the requirement (or fixed the bug)

• Constant refactoring of tests, code, and features enables continuous improvement

Alternatives to branching

• Most CD teams work almost entirely on HEAD

• Feature toggles can isolate incomplete features in a repeatable way

• Branch by abstraction works too

• It may take some time for a team to find the combination that works consistently for a given project

This sounds hard, why should I care?

So why does Continuous Delivery matter?

Continues Delivery lets you

Be Bold!

With a working pipeline and trusted tests, you can do radical things… and know quickly if they worked or not

Continuous Delivery ensures

A Stable Codebase• Every check-in generates a tested

build• Focus on testing ensures test

coverage and quality remains high• Ruthless refactoring helps to ensure

code rot doesn’t creep in• If you trust your tests, it’s easy to

be ruthless when refactoring!

Continuous Delivery enables

Extreme Agility

By eliminating the technical barriers to release, the business can be extremely nimble.

At Betfair, the minimum latency between feature definition and a fully tested, potentially releasable build was reduced to a matter of hours.

Cautionary Tales

(from the pipeline)

Questions?

mountwatatic@gmail.com

Resources

• Humble, J., & Farley, D. (2010) Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation. Addison Wesley

• Martin Fowler article on Continuous Integration: http://www.martinfowler.com/articles/continuousIntegration.html

• Jez Humble’s Continuous Delivery blog: http://continuousdelivery.com/