SlideShare utilise les cookies pour améliorer les fonctionnalités et les performances, et également pour vous montrer des publicités pertinentes. Si vous continuez à naviguer sur ce site, vous acceptez l’utilisation de cookies. Consultez nos Conditions d’utilisation et notre Politique de confidentialité.
SlideShare utilise les cookies pour améliorer les fonctionnalités et les performances, et également pour vous montrer des publicités pertinentes. Si vous continuez à naviguer sur ce site, vous acceptez l’utilisation de cookies. Consultez notre Politique de confidentialité et nos Conditions d’utilisation pour en savoir plus.
Agile and ITIL ContinuousDeliveryMaking Agile Continuous Delivery compatible with ITILchange management frameworksMartin Jackson@actionjack
“Suffering increases in proportion to knowledge ofa better way.”James A. Hickstein
The Problem• Agile Continuous Delivery perceived as incompatible withOperations team ITIL type change managementmethodology:• Need for speciﬁc versions of the application andsupporting tools• Change management process requires detailed speciﬁcs 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
Negotiation Deadlock• Always shipping from trunk - Lack of releasebranches• New functionality exposed by feature ﬂags -Lack of discrete features or ﬁxes 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 andpossible assumptions• Will version X be able inY Months (Withmultiple releases per day)?• Should the managing software versions anda deﬁnitive software library across multipleenvironments be a full time job?
Conﬂicting 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
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
The cost of long durationsbetween releases• Big releases are risky!• Big releases reduce code value (code depreciation)(http://martinfowler.com/bliki/FrequencyReducesDifﬁculty.html)
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)
Economic beneﬁts 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-ﬂow/)
Doing it more often requires a continuousintegration or delivery pipelineDoing it more often
• Example IT Change Management ProcessITIL Change ManagementProcess
Gap Analysis• How do we get the artifacts supplied byour continuous deployment pipelineintegrated into the change managementprocess?
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.
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 conﬁguration) e.g. Documentation,Software,Admin support scripts, etc...
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.
Deﬁnitive MediaLibrary• Pulp becomes our ITILv3 Deﬁnitive MediaLibrary• Vendor our upstream packages anddependencies• It also has support for mirroring puppetforge modules
Conclusion• Releases can ﬂow through the system in amanner that ﬁts all parties• As conﬁdence and trust grows we can movefrom normal to standard pre-approved releasesfurther increasing deployment velocity• Working towards making production releasesboring events rather than ﬁre drills• It adds predictability since the process ﬂow isshown from code creation to productiondeployment• Shared responsibility between all teamsinvolved in getting releases into production