Agile and ITIL Continuous Delivery

Making Agile Continuous Delivery compatible with ITIL change management frameworks

Martin Jackson@actionjack

“Suffering increases in proportion to knowledge of a better way.”

James A. Hickstein

The Problem• Agile Continuous Delivery perceived as incompatible with

Operations team ITIL type change management methodology:

• Need for specific versions of the application and supporting tools

• Change management process requires detailed specifics of what's in a "release" in order to assess possible impact

• Multiple environments that need to be maintained for integration, staging, performance, etc.

• Requirement to perform granular upgrades to existing environments

Negotiation Deadlock

• Always shipping from trunk - Lack of release branches

• New functionality exposed by feature flags - Lack of discrete features or fixes per release

• Package version availability (or rather lack of) i.e who cares about version X in 6 months?

• Reliance on Rolling Forward vs Back

Valid questions and possible assumptions

• Will version X be able in Y Months (With multiple releases per day)?

• Should the managing software versions and a definitive software library across multiple environments be a full time job?

Conflicting priorities and incentives

• Customers want features

• Business wants to quickly deliver features to customers in a reliable and stable manner

• Developers want change to enable features

• Operations want stability and minimal changes

But...

• We build a release candidate on every successful commit

• New functionality gets added all the time

• A lot can change if you don’t ship regularly

• If you skip xxx revisions deployment risk increases

The cost of long durations between releases

• Big releases are risky!

• Big releases reduce code value (code depreciation)(http://martinfowler.com/bliki/FrequencyReducesDifficulty.html)

Big Changes are scary• If Big Changes are scary lets split them into

small batches

• Small batches mean faster feedback

• Small batches mean problems are instantly localized

• Small batches reduce risk

• Small batches reduce overhead(http://www.startuplessonslearned.com/2009/02/work-in-small-batches.html)

Economic benefits of small batch sizes

• Donald G. Reinertsen’s “The Principles of Product Development Flow”, page 121

(http://dev2ops.org/2012/03/devops-lessons-from-lean-small-batches-improve-flow/)

Doing it more often requires a continuous integration or delivery pipeline

Doing it more often

• Example IT Change Management Process

ITIL Change Management Process

Gap Analysis

• How do we get the artifacts supplied by our continuous deployment pipeline integrated into the change management process?

Working towards the ITIL Standard change

Additional Tooling

• As part of our Continuous Integration process we deliver RPM Packages

• RPM Packages are hosted in a package repository and for drop off to our demo environments and pulp.

Why RPM’s?• Our selected OS's default package manager

• Deployment is easy for Traditional Operations Teams

• We are packaging a package but the incremental work performed to create them more than paid for itself in terms of communications overhead for release coordination

• We want to package almost everything in a RPM (excluding configuration) e.g. Documentation, Software, Admin support scripts, etc...

Pulp?• Pulp is a platform for managing repositories of content, such

as software packages, and pushing that content out to large numbers of consumers

• Pulp can walk software packages through development, testing, and stable repositories, pushing those updates out to client machines as they get promoted.

Definitive Media Library

• Pulp becomes our ITILv3 Definitive Media Library

• Vendor our upstream packages and dependencies

• It also has support for mirroring puppet forge modules

Pulp Methodology

Initial Normal Change Flow

Target Standard change flow (Electronic approval)

Mapping the flow

May look complicated but...

a tool like Jenkins can orchestrate this making it easier

Updated CD Pipeline

Conclusion• Releases can flow through the system in a

manner that fits all parties

• As confidence and trust grows we can move from normal to standard pre-approved releases further increasing deployment velocity

• Working towards making production releases boring events rather than fire drills

• It adds predictability since the process flow is shown from code creation to production deployment

• Shared responsibility between all teams involved in getting releases into production

Questions?

Links• http://www.itil-officialsite.com

• http://continuousdelivery.com

• http://martinfowler.com/bliki/FrequencyReducesDifficulty.html

• http://www.startuplessonslearned.com/2009/02/work-in-small-batches.html

• http://dev2ops.org/2012/03/devops-lessons-from-lean-small-batches-improve-flow/

• http://continuousdelivery.com/2010/11/continuous-delivery-and-itil-change-management/

• http://www.pulpproject.org

• http://jenkins-ci.org