continuous delivery: what it isn't; what it is; why it matters
DESCRIPTION
Continuous Delivery: What it isn't What it is Why it matters Continuous Delivery has become a hot topic in the software field, and there's a lot of confusion around the topic. These slides were written to accompany a talk at Develop: BBC, which was delivered in Salford, UK, on 12 November, 2013.TRANSCRIPT
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)
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/