Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Five (easy?) Steps Towards Continuous Delivery

731 views

Published on

Presentation from JAX 2016 about how to start with Continuous Delivery.

Published in: Software
  • Be the first to comment

Five (easy?) Steps Towards Continuous Delivery

  1. 1. Five (easy?) Steps Towards Continuous Delivery Eberhard Wolff @ewolff innoQ
  2. 2. http://continuous-delivery-buch.de/
  3. 3. http://microservices-buch.de/ http://microservices-book.com/
  4. 4. http://microservices-book.com/primer.html FREE!!!!
  5. 5. What is CD?
  6. 6. Continuous Delivery = Deployment automation
  7. 7. Continuous Delivery = Deployment automation to increase speed
  8. 8. Production problem. Boss screams at you. How long to production? <15 min <30 min <60 min >60 min >1 day
  9. 9. OH “The application server takes 15 min to start.”
  10. 10. Why don’t we deliver software every day into production?
  11. 11. Old release Hot fix Old release New release
  12. 12. Risk of bug fix small compared to keeping faulty release in production.
  13. 13. Would we deliver into production more often if it took e.g. 5 minutes?
  14. 14. Would we deliver software into production more often with Puppet, Chef, Docker?
  15. 15. Step One Realize deployment automation is just a prerequisite for Continuous Delivery!
  16. 16. Continuous Delivery = Deployment automation to increase speed
  17. 17. Continuous Delivery = Deployment automation to increase speed
  18. 18. What is CD?
  19. 19. Agile Manifesto Principles Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  20. 20. Build Pipeline Commit Stage Automated Acceptance Testing Automated Capacity Testing Manual Explorative Testing Release Many tests to minimize risk Infrastructure automation Fast Feedback
  21. 21. Why Continuous Delivery? > Faster Deployment > Higher Reliability > Reproducibility
  22. 22. Why Continuous Delivery? > Cost-savings hard to estimate > CD is an important step towards better and faster results €
  23. 23. Understand the Goal! > Seemingly simple > …but often forgotten > Not just about time-to-market > Might also be reliability!
  24. 24. Reliability > Errors hard to reproduce > Software hard to install > Invest in deployment automation > Ensure environment is identical in development and production
  25. 25. Time-to-Market > Optimize processing time! > There is already a pipeline > Goal: Constant flow of features through the pipeline > Optimize throughput
  26. 26. Value Stream Mapping > Analyze existing pipeline > Optimize throughput
  27. 27. Commit Acceptance Testing Capacity Testing Release Delay Lead Time 5 Days 2 Days 1 Day 1 day 1 day 1 day Automated Acceptance Testing Automated Capacity Testing Testing, Sign Off & Release Cycle Time = Delay + Lead Time 1 hour 20 minutes 20 minutes 30 minutes 2 Day 2 day
  28. 28. Commit Acceptance Testing Capacity Testing Release Delay Lead Time 5 Days 2 Days 1 Day 1 day 1 day 1 day Automated Acceptance Testing Automated Capacity Testing Testing, Sign Off & Release Cycle Time = Delay + Lead Time 1 hour 20 minutes 20 minutes 30 minutes 2 Day 2 day 11 days 5 days
  29. 29. Result > Cycle time reduced: Automated tests faster > …and less effort > Still manual sign-off & Release > Feedback faster: Early 80% acceptance test
  30. 30. Goal: Reliability Deployment Automation Goal: Time-to-Market Value Stream Mapping Fast Feedback
  31. 31. Step Two Understand goals! Take pragmatic steps!
  32. 32. Commit Automated Acceptance Testing Automated Capacity Testing Testing, Sign Off & Release 1 hour 2 day Why Sign Off? Acceptance test = software is accepted
  33. 33. Why Sign-Off? > Customer wants to check the final result. > Understandable > But: Slow > But: Hard to reproduce
  34. 34. Eliminate manual Sign-off!
  35. 35. Sign-off->Automated Tests > Automated tests are fast > …and easily reproducible > …and cheaper > Obviously the better choice!
  36. 36. Why Sign-off? > Risk of deploying the wrong software > Lack of trust in tests > Risk handling strategy
  37. 37. Handling risk > Make it easier to resolve issues > Make deployment easier and faster > Problem in production easier to fix > Deployment automation
  38. 38. Old release New release
  39. 39. Old release New release New release New release New release
  40. 40. Handling risk > Smaller deployments > More frequent deployments > Less risk that an error sneaks in > Easier to reverse
  41. 41. Creating Trust > Customer must understand the tests > Reviews > Use proper kind of tests
  42. 42. Automated Acceptance Tests Automated Integration Tests Unit Tests Manual Tests Test Pyramid Visible to customer
  43. 43. The ultimate requirement is an automated acceptance test. XP 1999
  44. 44. UI Tests: Selenium > Easy to start > Natural for testers > Fragile > Loose semantics
  45. 45. Behavior-driven development: Example Scenario: User registers successfully Context Event Expected outcome Given a new user with email eberhard.wolff@gmail.com firstname Eberhard name Wolff When the user registers Then a customer with email eberhard.wolff@gmail.com should exist And no error should be reported
  46. 46. Creating Trust > UI Tests are overused and have drawbacks > BDD is designed for customers > But most important: > Choose whatever the customer understands! > UI tests might be OK
  47. 47. Step Three Eliminate manual sign-offs! Create trust in tests!
  48. 48. CD & DevOps > Usually Dev wants Continuous Delivery (CD) > Dev wants easier and faster releases > Ops not supportive > However, they should aim for less risky deployments…
  49. 49. Ops > Optimized for costs > Caught in a local optimum > i.e. standardized environments > …but manual deployment > Large investment for full automation > Continuous Delivery problem to be expected
  50. 50. Commit Automated Acceptance Testing Automated Capacity Testing Testing, Sign Off & Release Dev Ops
  51. 51. CD & DevOps > No need to create DevOps teams > Collaboration needed, though > Deployment is a joined Ops / Dev effort > Good news: No reorganzation
  52. 52. CD & DevOps > Seek feedback from Ops early on > Try to leverage Ops experience
  53. 53. DevOps is no organization.
  54. 54. DevOps is collaboration.
  55. 55. Step Four Deal with the gap between Dev and Ops!
  56. 56. Continuous Delivery: Build Pipeline ECommerce System Commit Stage Automated Acceptance Testing Automated Capacity Testing Manual Explorative Testing Release
  57. 57. ECommerce System 3rd party systems Database
  58. 58. Challenges > Dependencies on 3rd party systems > Must provide test systems > …or mocks > Large database > Must provide test data
  59. 59. Challenges > Tests take too long > Deployment takes too long > Continuous Delivery pipeline takes far too long
  60. 60. Continuous Delivery with large deployment units is hard.
  61. 61. Like real hard.
  62. 62. Server Server Microservices > Independent deployment units > E.g. process, VMs, Docker containers > Any technology > Any infrastructure Micro Service Micro Service
  63. 63. Microservices ECommerce System 3rd party systems Database
  64. 64. Microservices 3rd party systems Database Order Catalog Billing Search
  65. 65. Order Billing Customer Commit Stage Automated Acceptance Testing Automated Capacity Testing Manual Explorative Testing Release Commit Stage Automated Acceptance Testing Automated Capacity Testing Manual Explorative Testing Release Commit Stage Automated Acceptance Testing Automated Capacity Testing Manual Explorative Testing Release
  66. 66. Microservice Pipeline > Build pipeline per Microservice > Small > Easy to set up > Simpler (3rd party systems) > Faster Feedback: Less tests > Separate critical and less critical parts
  67. 67. Migrate to Microservices > Add Microservices to existing system > Implement new features in Microservices > No need to redo the full application
  68. 68. Continuous Delivery doesn’t mean Microservices.
  69. 69. But can you do Continuous Delivey without supporting it in the architecture?
  70. 70. Step Five Adjust the architecture!
  71. 71. Conclusion
  72. 72. Final words > Do no underestimate the effort! > This is not about automation to save cost. > It is about increasing quality!
  73. 73. Conclusion > Deployment automation is just a prerequisite > Understand the goals! Take pragmatic steps! > Eliminate sign-offs! Create trust in tests! > Deal with the gap between Dev and Ops! > Adjust the architecture!
  74. 74. Thank You! @ewolff

×