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