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.

It's Not Continuous Delivery If You Can't Deploy Right Now


Published on

Talk from DevOpsDays Raleigh, Sep 7 2017

Published in: Software
  • Great information about writing! If you ever need any help with proofreading, editing or research check out Writer’s Help. They are a great resource for personal, educational or business writing needs. The website is ⇒ ⇐
    Are you sure you want to  Yes  No
    Your message goes here
  • Be the first to like this

It's Not Continuous Delivery If You Can't Deploy Right Now

  1. 1. @kmugrage IT’S NOT CONTINUOUS DELIVERY If you can’t deploy to production right now
  2. 2. @kmugrage WhoAm I? Ken Mugrage ThoughtWorks Technology Evangelist DevOpsDays Core Organizer @kmugrage
  3. 3. @kmugrage – Me “DevOps: A culture where people, regardless of title or background, work together to imagine, develop, deploy and operate a system.”
  4. 4. @kmugrage Jez Humble - “Continuous Delivery is the ability to get changes of all types—including new features, configuration changes, bug fixes and experiments—into production, or into the hands of users, safely and quickly in a sustainable way.”
  5. 5. @kmugrage WHY THIS TALK?
  6. 6. @kmugrage There is no try
  7. 7. @kmugrage Why continuous delivery? We follow these principles: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  8. 8. @kmugrage Partially“done” might still be useful
  9. 9. @kmugrage Respond to security issues At the time of disclosure, some 17% (around half a million) of the Internet's secure web servers certified by trusted authorities were believed to be vulnerable to the attack, allowing theft of the servers' private keys and users' session cookies and passwords.
  10. 10. @kmugrage Knight Capital To be continued….
  11. 11. @kmugrage CONTINUOUS INTEGRATION A pre-requisite to Continuous Delivery
  12. 12. @kmugrage The ThoughtWorks tech radar recently recommended putting a hold on the tech team anti-pattern, CI Theatre. CI Theatre describes the illusion of practicing continuous integration (CI) while not really practicing it.
  13. 13. @kmugrage In our study only 10% of participants acknowledged that having a CI server was not the same as practicing CI.
  14. 14. @kmugrage Continuous Integration Everyone pushes their code into trunk / master (not feature branches) on a daily basis Every commit triggers your tests When the build is broken, it is typically fixed within 10 minutes
  15. 15. @kmugrage Feature Branching
  16. 16. @kmugrage Feature Branching
  17. 17. @kmugrage Feature Branching
  18. 18. @kmugrage PipelinesYou Should Be Including
  19. 19. @kmugrage Security testing Test before you commit Static Application Security Testing (SAST) Dynamic Application Security Testing (DAST)
  20. 20. @kmugrage Performance testing Load testing Stress testing Soak testing Spike testing
  21. 21. @kmugrage Unit Test Functional Test Load Test Staging Production Spike Test Stress Test Soak Test Run as much as possible in parallel
  22. 22. @kmugrage Run as much as possible in parallel
  23. 23. @kmugrage You should decide the order, not your tool
  24. 24. @kmugrage Deploying incomplete work How to deliver faster than you can finish a feature
  25. 25. @kmugrage Feature Toggles
  26. 26. @kmugrage Feature Toggles Pete Hodgson -
  27. 27. @kmugrage Feature Toggles Pete Hodgson -
  28. 28. @kmugrage Branch by Abstraction Consumer Consumer Component
  29. 29. @kmugrage Branch by Abstraction Consumer Consumer Component Abstraction
  30. 30. @kmugrage Branch by Abstraction Consumer Consumer Old Abstraction New
  31. 31. @kmugrage Managing risk
  32. 32. @kmugrage Optimize for recovery Mean time between failures (MTBF) is the predicted elapsed time between inherent failures of a system during operation. Mean Time To Repair (MTTR) is a basic measure of the maintainability of repairable items. It represents the average time required to repair a failed component or device.
  33. 33. @kmugrage Deployment patterns Canary release A technique to reduce the risk of introducing a new software version in production by slowly rolling out the change to a small subset of users before rolling it out to the entire infrastructure and making it available to everybody. Dark launching The practice of deploying the very first version of a service into its production environment, well before release, so that you can soak test it and find any bugs before you make its functionality available to users.
  34. 34. @kmugrage Feedback loops Create useful logging for everything Run (some of) your tests against production Ensure alerts are useful as well
  35. 35. @kmugrage Knight Capital On August 1, 2012, Knight Capital deployed untested software to a production environment which contained an obsolete function.The incident happened due to a technician forgetting to copy the new Retail Liquidity Program (RLP)…. …sent millions of child orders, resulting in 4 million executions in 154 stocks for more than 397 million shares in approximately 45 minutes. Knight Capital took a pre-tax loss of $440,000,000
  36. 36. @kmugrage Summary It’s not Continuous Delivery if you can’t deploy right now Practice good CI habits Use things like feature toggles to deploy incomplete work
  37. 37. @kmugrage THANKYOU To learn more about ThoughtWorks Products Ken Mugrage @kmugrage