bcn devcon jose luis soria - patterns & antipatterns for delivery
DESCRIPTION
Slides for the session about release management practices at Barcelona Developers Conference 2013TRANSCRIPT
PATTERNS & ANTIPATTERNSFOR (CONTINUOUS) DELIVERY
Jose Luis Soria [email protected] - @jlsoriat
Barcelona, November 9th 2013
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Principles behind the Agile Manifesto
How long would it take your organization to deploy a change that involves just one single line of code?
Do you do this on a repeatable, reliable basis?
Mary & Tom PoppendieckImplementing Lean Software Development
Done means "released". This implies ownership of a project right up until it’s in the hands of the user, and working properly. There’s none of this "I’ve checked in my code so it’s done as far as I’m concerned".
James Betteley
Just ship, baby.
Kent Beck, http://www.threeriversinstitute.org/JustShip.html
SOFTWAREDELIVERYMODELS
#1: No model, or random delivery.
#2: Let the operations guys figure out.
#3: Defined and collaborative approach.
DELIVERY PATTERNS & PRACTICES
Do you exclude from versioningartifacts like databases, configuration files, binaries, documentation, tools orenvironments?
That is, do you fail to effectively do thefollowing, for any needed version of theseartifacts?Backup.Get from history.Undo changes.Work with other people.Audit and track changes.Keep stable copies.Etc.
Versioneverything.
Do you manually perform any of these?
Building.Packaging.Deploying.Testing.Environment provisioning.
Or, do you make mistakes because of missingsteps, misunderstandings, boredom, etc.?
Do you waste time that could be employed in building and delivering value?
Do you depend on specific people to get theseactivities done?
Do accidents frequently happen in yourproject?
Automateeverything.
Do you manually copy or changeconfiguration files to match eachtarget environment?
So, do you need to remember whichconfiguration files must be changed and whatthe changes are?
Do you make mistakes or omissions whendoing these changes?
Are you exposing sensitive information aboutthe environments?
Tokenizeconfigurations.
Do you follow a complexprocedure for deployments, withmultiple steps involved?
In other words, do you spend a lot of time and effort in each deployment?
Do you avoid testing some versions in someenvironments because deployment is painful?
Use one-click deployments.
ARIANNE 5 FLIGHT 501 EXPLOSION
In 1996, the Ariane 5 rocket was reusing software from the Ariane 4. Ariane 5’s faster engines exploited a bug that was not realized before: the software tried to cram a 64-bit number into a 16-bit space. 36.7 seconds into its maiden launch, the self destruct safety mechanism was activated.
http://en.wikipedia.org/wiki/Ariane_5#Notable_launches
SIBERIAN PIPELINE SABOTAGE
In 1982, CIA introduced a bug into the Soviet gas pipeline system, that passed preliminary inspection but made the system fail when in operation. It led to the largest non-nuclear explosion ever.
http://en.wikipedia.org/wiki/Siberian_pipeline_sabotage
Do you validate your applicationonly in development or testingenvironments?
That is, do you lack informationabout how your application willbehave in the productionenvironment?
Deploy to a copyof production.
Do you follow differentprocedures for deploying todifferent environments?
… making your deploymentprocedure is more vulnerable toenvironment-specific issues?
Is that procedure poorly tested?
Deploy the same way to everyenvironment
Do you skip the preparation of rollback mechanisms before a deployment?
Or, if a deployment (or the deployedversion) fails, do you need to figure outhow to get the system running again?
Does that take a lot of time and effort?
Is the business losing lots of money
meanwhile?
Have always a rollbackmechanism in place.
Does anyone in your team makemanual changes to theenvironments?
…resulting in frequently spoiled orwasted environments?
Do you have to recreate or reconfigure them so often?
Does it happen without even noticing, until it’s too late?
Lock down
the environments.
Do you build binaries from thesame code several times duringthe release process?
So, do you ship binaries that have notbeen tested?
Do you waste time and resources
building the same thing again and again?
Do you introduce errors because of
different build sequences?
Buildonlyonce.
Do you fail to gather and analyzing data about yourdelivery process?
Or, do you lack a baseline thatyou can use to supportimprovement actions?
Measure the delivery process.
Do you consistently avoid painfulsteps in your delivery process?
And are you leaving sensitive stepsfor the last moment?
Do you fail to practice and master critical aspects of the deliverysequence?
Bring the pain forward
Do you lack the support of operations people for definingthe delivery process and artifacts?
That is, are you not collaboratingwith the people that have someof the key knowledge and control?
PracticeDevOps!
Do you lack a defined, repeatable, robust and fastdelivery process?
So, are you failing to delivereffectively?
Build a release pipeline.
What about your own patterns & practices?
1. Think about some deliverypractice not covered in thesession.
2. Tweet it.
#bdc13 @jlsoriat
3. Benefit!
http://aka.ms/ReleasePipeline
Thanks!
@jlsoriat
http://geeks.ms/blogs/jlsoria
Get my e-book (for free): http://aka.ms/ReleasePipelineGet the labs: http://aka.ms/ReleasePipeline-HOLGet these slides: http://slidesha.re/1hVyKvt
Any questions?