Agile and ITIL Continuous Delivery

Making Agile Continuous Delivery compatible with ITIL change management frameworks

Transcript

1. Agile and ITIL Continuous Delivery Making Agile Continuous Delivery compatible with ITIL change management frameworks Martin Jackson @actionjack
2. “Suffering increases in proportion to knowledge of a better way.” James A. Hickstein
3. 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
4. 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
5. 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?
6. 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
7. 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
8. The cost of long durations between releases • Big releases are risky! • Big releases reduce code value (code depreciation) (http://martinfowler.com/bliki/FrequencyReducesDifficulty.html)
9. 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)
10. 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/)
11. Doing it more often requires a continuous integration or delivery pipeline Doing it more often
12. • Example IT Change Management Process ITIL Change Management Process
13. Gap Analysis • How do we get the artifacts supplied by our continuous deployment pipeline integrated into the change management process?
14. Working towards the ITIL Standard change
15. 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.
16. 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...
17. 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.
18. 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
19. Pulp Methodology
20. Initial Normal Change Flow
21. Target Standard change flow (Electronic approval)
22. Mapping the flow May look complicated but... a tool like Jenkins can orchestrate this making it easier
23. Updated CD Pipeline
24. 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
25. Questions?
26. 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