Bcn devcon jose luis soria - patterns & antipatterns for delivery


Published on

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

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Bcn devcon jose luis soria - patterns & antipatterns for delivery

  1. 1. PATTERNS & ANTIPATTERNS FOR (CONTINUOUS) DELIVERY Jose Luis Soria Teruel - @jlsoriat Barcelona, November 9th 2013
  2. 2. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Principles behind the Agile Manifesto
  3. 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. 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. 5. Just ship, baby. Kent Beck,
  7. 7. #1: No model, or random delivery.
  8. 8. #2: Let the operations guys figure out.
  9. 9. #3: Defined and collaborative approach.
  11. 11. Do you exclude from versioning artifacts like databases, configuration files, binaries, documentation, tools or environments?
  12. 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. 13. Version everything.
  14. 14. Do you manually perform any of these? Building. Packaging. Deploying. Testing. Environment provisioning.
  15. 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. 16. Automate everything.
  17. 17. Do you manually copy or change configuration files to match each target environment?
  18. 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. 19. Tokenize configurations.
  20. 20. Do you follow a complex procedure for deployments, with multiple steps involved?
  21. 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. 22. Use one-click deployments.
  23. 23.
  24. 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.
  25. 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.
  26. 26. Do you validate your application only in development or testing environments?
  27. 27. That is, do you lack information about how your application will behave in the production environment?
  28. 28. Deploy to a copy of production.
  29. 29. Do you follow different procedures for deploying to different environments?
  30. 30. … making your deployment procedure is more vulnerable to environment-specific issues? Is that procedure poorly tested?
  31. 31. Deploy the same way to every environment
  32. 32. Do you skip the preparation of rollback mechanisms before a deployment?
  33. 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. 34. Have always a rollback mechanism in place.
  35. 35. Does anyone in your team make manual changes to the environments?
  36. 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?
  37. 37. Lock down the environments.
  38. 38. Do you build binaries from the same code several times during the release process?
  39. 39. 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?
  40. 40. Build only once.
  41. 41. Do you fail to gather and analyzing data about your delivery process?
  42. 42. Or, do you lack a baseline that you can use to support improvement actions?
  43. 43. Measure the delivery process.
  44. 44. Do you consistently avoid painful steps in your delivery process?
  45. 45. And are you leaving sensitive steps for the last moment? Do you fail to practice and master critical aspects of the delivery sequence?
  46. 46.
  47. 47. Bring the pain forward
  48. 48. Do you lack the support of operations people for defining the delivery process and artifacts?
  49. 49. That is, are you not collaborating with the people that have some of the key knowledge and control?
  50. 50. Practice DevOps!
  51. 51. Do you lack a defined, repeatable, robust and fast delivery process?
  52. 52. So, are you failing to deliver effectively?
  53. 53. Build a release pipeline.
  54. 54. What about your own patterns & practices? 1. Think about some delivery practice not covered in the session. 2. Tweet it. #bdc13 @jlsoriat 3. Benefit!
  55. 55. Thanks! Any questions? @jlsoriat Get my e-book (for free): Get the labs: Get these slides: