Your SlideShare is downloading. ×
  • Like
Agile and ITIL Continuous Delivery
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Agile and ITIL Continuous Delivery

  • 4,791 views
Published

Making Agile Continuous Delivery compatible with ITIL change management frameworks

Making Agile Continuous Delivery compatible with ITIL change management frameworks

Published in Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
4,791
On SlideShare
0
From Embeds
0
Number of Embeds
3

Actions

Shares
Downloads
153
Comments
0
Likes
12

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Agile and ITIL ContinuousDeliveryMaking Agile Continuous Delivery compatible with ITILchange management frameworksMartin Jackson@actionjack
  • 2. “Suffering increases in proportion to knowledge ofa better way.”James A. Hickstein
  • 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. 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. 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. 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. 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. The cost of long durationsbetween 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 intosmall batches• Small batches mean faster feedback• Small batches mean problems areinstantly localized• Small batches reduce risk• Small batches reduce overhead(http://www.startuplessonslearned.com/2009/02/work-in-small-batches.html)
  • 10. Economic benefits of smallbatch 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 continuousintegration or delivery pipelineDoing it more often
  • 12. • Example IT Change Management ProcessITIL Change ManagementProcess
  • 13. Gap Analysis• How do we get the artifacts supplied byour continuous deployment pipelineintegrated into the change managementprocess?
  • 14. Working towards the ITILStandard change
  • 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. 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. 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. Definitive MediaLibrary• Pulp becomes our ITILv3 Definitive MediaLibrary• Vendor our upstream packages anddependencies• It also has support for mirroring puppetforge modules
  • 19. Pulp Methodology
  • 20. Initial Normal Change Flow
  • 21. Target Standard changeflow (Electronic approval)
  • 22. Mapping the flowMay 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 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. 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