Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Agile and ITIL Continuous Delivery


Published on

Making Agile Continuous Delivery compatible with ITIL change management frameworks

Published in: Technology, Business

Agile and ITIL Continuous Delivery

  1. 1. Agile and ITIL ContinuousDeliveryMaking Agile Continuous Delivery compatible with ITILchange management frameworksMartin Jackson@actionjack
  2. 2. “Suffering increases in proportion to knowledge ofa better way.”James A. Hickstein
  3. 3. The Problem• Agile Continuous Delivery perceived as incompatible withOperations team ITIL type change managementmethodology:• Need for specific versions of the application andsupporting tools• Change management process requires detailed specifics ofwhats in a "release" in order to assess possible impact• Multiple environments that need to be maintained forintegration, staging, performance, etc.• Requirement to perform granular upgrades to existingenvironments
  4. 4. Negotiation Deadlock• Always shipping from trunk - Lack of releasebranches• 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. 5. Valid questions andpossible assumptions• Will version X be able inY Months (Withmultiple releases per day)?• Should the managing software versions anda definitive software library across multipleenvironments be a full time job?
  6. 6. Conflicting prioritiesand incentives• Customers want features• Business wants to quickly deliver features tocustomers in a reliable and stable manner• Developers want change to enable features• Operations want stability and minimalchanges
  7. 7. But...• We build a release candidate on everysuccessful commit• New functionality gets added all the time• A lot can change if you don’t ship regularly• If you skip xxx revisions deployment riskincreases
  8. 8. The cost of long durationsbetween releases• Big releases are risky!• Big releases reduce code value (code depreciation)(
  9. 9. Big Changes are scary• If Big Changes are scary lets split them intosmall batches• Small batches mean faster feedback• Small batches mean problems areinstantly localized• Small batches reduce risk• Small batches reduce overhead(
  10. 10. Economic benefits of smallbatch sizes• Donald G. Reinertsen’s “The Principles of Product Development Flow”, page 121(
  11. 11. Doing it more often requires a continuousintegration or delivery pipelineDoing it more often
  12. 12. • Example IT Change Management ProcessITIL Change ManagementProcess
  13. 13. Gap Analysis• How do we get the artifacts supplied byour continuous deployment pipelineintegrated into the change managementprocess?
  14. 14. Working towards the ITILStandard change
  15. 15. Additional Tooling• As part of our Continuous Integrationprocess we deliver RPM Packages• RPM Packages are hosted in a packagerepository and for drop off to our demoenvironments and pulp.
  16. 16. Why RPM’s?• Our selected OSs default package manager• Deployment is easy for Traditional OperationsTeams• We are packaging a package but the incrementalwork performed to create them more than paidfor itself in terms of communications overhead forrelease coordination• We want to package almost everything in a RPM(excluding configuration) e.g. Documentation,Software,Admin support scripts, etc...
  17. 17. Pulp?• Pulp is a platform for managing repositories of content, suchas software packages, and pushing that content out to largenumbers of consumers• Pulp can walk software packages through development,testing, and stable repositories, pushing those updates out toclient machines as they get promoted.
  18. 18. Definitive MediaLibrary• Pulp becomes our ITILv3 Definitive MediaLibrary• Vendor our upstream packages anddependencies• It also has support for mirroring puppetforge modules
  19. 19. Pulp Methodology
  20. 20. Initial Normal Change Flow
  21. 21. Target Standard changeflow (Electronic approval)
  22. 22. Mapping the flowMay look complicated but...a tool like Jenkins can orchestrate this making it easier
  23. 23. Updated CD Pipeline
  24. 24. Conclusion• Releases can flow through the system in amanner that fits all parties• As confidence and trust grows we can movefrom normal to standard pre-approved releasesfurther increasing deployment velocity• Working towards making production releasesboring events rather than fire drills• It adds predictability since the process flow isshown from code creation to productiondeployment• Shared responsibility between all teamsinvolved in getting releases into production
  25. 25. Questions?
  26. 26. Links••••••••