Slides for the session about release management practices at Barcelona Developers Conference 2013

1. PATTERNS & ANTIPATTERNS
FOR (CONTINUOUS) DELIVERY
Jose Luis Soria Teruel
jlsoria@plainconcepts.com - @jlsoriat
Barcelona, November 9th 2013

2. Our highest priority is to satisfy the customer
through early and continuous delivery of
valuable software.
Principles behind the Agile Manifesto

3. 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 Poppendieck
Implementing Lean Software Development

4. 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

5. Just ship, baby.
Kent Beck, http://www.threeriversinstitute.org/JustShip.html

6. SOFTWARE
DELIVERY
MODELS

7. #1: No model, or random delivery.

8. #2: Let the operations guys figure out.

9. #3: Defined and collaborative approach.

10. DELIVERY PATTERNS & PRACTICES

11. Do you exclude from versioning
artifacts like databases,
configuration files, binaries,
documentation, tools or
environments?

12. That is, do you fail to effectively do the
following, for any needed version of these
artifacts?
Backup.
Get from history.
Undo changes.
Work with other people.
Audit and track changes.
Keep stable copies.
Etc.

13. Version
everything.

14. Do you manually perform any of these?
Building.
Packaging.
Deploying.
Testing.
Environment provisioning.

15. Or, do you make mistakes because of missing
steps, misunderstandings, boredom, etc.?
Do you waste time that could be employed in
building and delivering value?
Do you depend on specific people to get these
activities done?
Do accidents frequently happen in your
project?

16. Automate
everything.

17. Do you manually copy or change
configuration files to match each
target environment?

18. So, do you need to remember which
configuration files must be changed and what
the changes are?
Do you make mistakes or omissions when
doing these changes?
Are you exposing sensitive information about
the environments?

19. Tokenize
configurations.

20. Do you follow a complex
procedure for deployments, with
multiple steps involved?

21. In other words, do you spend a lot of time
and effort in each deployment?
Do you avoid testing some versions in some
environments because deployment is painful?

22. Use one-click deployments.

23. http://bit.ly/HNQJWo

24. 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

25. 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

26. Do you validate your application
only in development or testing
environments?

27. That is, do you lack information
about how your application will
behave in the production
environment?

28. Deploy to a copy
of production.

29. Do you follow different
procedures for deploying to
different environments?

30. … making your deployment
procedure is more vulnerable to
environment-specific issues?
Is that procedure poorly tested?

31. Deploy the same way to every
environment

32. Do you skip the preparation of
rollback mechanisms before a
deployment?

33. Or, if a deployment (or the deployed
version) fails, do you need to figure out
how to get the system running again?
Does that take a lot of time and effort?
Is the business losing lots of money
meanwhile?

34. Have always a rollback
mechanism in place.

35. Does anyone in your team make
manual changes to the
environments?

36. …resulting in frequently spoiled or
wasted environments?
Do you have to recreate or reconfigure
them so often?
Does it happen without even noticing,
until it’s too late?

38. Lock down
the environments.

39. Do you build binaries from the
same code several times during
the release process?

40. So, do you ship binaries that have not
been tested?
Do you introduce errors because of
different build sequences?
Do you waste time and resources
building the same thing again and again?

41. Build
only
once.

42. Do you fail to gather and
analyzing data about your
delivery process?

43. Or, do you lack a baseline that
you can use to support
improvement actions?

44. Measure the delivery process.

45. Do you consistently avoid painful
steps in your delivery process?

46. And are you leaving sensitive steps
for the last moment?
Do you fail to practice and master
critical aspects of the delivery
sequence?

47. http://bit.ly/70eM6U

48. Bring the pain forward

49. Do you lack the support of
operations people for defining
the delivery process and
artifacts?

50. That is, are you not collaborating
with the people that have some
of the key knowledge and
control?

51. Practice
DevOps!

52. Do you lack a defined,
repeatable, robust and fast
delivery process?

53. So, are you failing to deliver
effectively?

54. Build a release pipeline.

58. What about your own patterns & practices?
1. Think about some delivery
practice not covered in the
session.
2. Tweet it.
#bdc13 @jlsoriat
3. Benefit!
http://aka.ms/ReleasePipeline

59. Thanks! Any questions?
jlsoria@plainconcepts.com
@jlsoriat
http://geeks.ms/blogs/jlsoria
Get my e-book (for free): http://aka.ms/ReleasePipeline
Get the labs: http://aka.ms/ReleasePipeline-HOL
Get these slides: http://slidesha.re/1hVyKvt