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.

Continuous Delivery

1,127 views

Published on

My April talk at boston-rb. The code examples can be found on github: https://github.com/bkaney/continuous-delivery-talk

Published in: Technology, Business
  • Be the first to comment

Continuous Delivery

  1. 1. Brian Kaney brian@vermonster.com bkaney, @bkaneyContinuous Delivery vermo nster
  2. 2. Here’s a ProblemChange Time
  3. 3. Delivery HazardChange The amount of risk and uncertainty when delivering change. Time
  4. 4. Scheduled ReleasesChange Lots of time, lots of changes. Larger area = larger hazard Time
  5. 5. Scheduled Releases• Lots of change over a lot of time• High level of deployment hazard• Scary, sweat, fear, etc.
  6. 6. Scheduled Releases Deadlines
  7. 7. Scheduled Releases Deadlines
  8. 8. Agile ManifestoIndividuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a planThat is, while there is value in the items on the right, wevalue the items on the left more. http://agilemanifesto.org
  9. 9. Iterations Sprint 4Change Sprint 3 Sprint 2 Less time and less change Less area = Less hazard Sprint 1 Time
  10. 10. Iterations• Less hazard per deploy• “Production” deployments are routine• Sprints are a series of micro-deadlines
  11. 11. Iterations• Less hazard per deploy• “Production” deployments are routine• Sprints are a series of micro-deadlines still has the word “dead”
  12. 12. What if...Change Release features individually as soon as they are ready. Lowest level of hazard Time
  13. 13. Continuous Delivery• Release features as soon as they are ready• No prescribed deadlines• Remove stigma from releasing to production (because everyone has to release often)
  14. 14. What does “Ready” Mean?• Does it pass CI?• Approved by Customer?• SQA?• Smoke Testing?
  15. 15. What does “Ready” Mean? Depends on the team’s risk threshold... Green CI Approval SQA Smoke TestFaster SlowerRisker Safer
  16. 16. CD Challenges?✓Determine Risk• Project Management• Technical Challenges
  17. 17. Kanban Intro• Signboard• Consisting of bins w/ two wells• Pull-based
  18. 18. Signboard
  19. 19. Signboard“Bins” arranged to match flow
  20. 20. Signboard WIP Limit
  21. 21. Signboard Bifurcation“in progress” and “ready to pull”
  22. 22. Signboard
  23. 23. Signboard
  24. 24. Signboard
  25. 25. Signboard
  26. 26. Signboard High PriorityBacklog Bottleneck!
  27. 27. Kanban Metrics?• No time-boxed development• No estimation• Velocity is replaced by cycle time (e.g. takes 2 days to deploy a card)• Throughput is development efficiency (e.g. we are moving 5 cards a week)
  28. 28. Little’s LawFor a queueing system in steady state, the averagelength of the queue is equivalent to the averagearrival rate multiplied by the average waiting time. L = λW - or - WIP (L)Cycle Time (W) = Throughput (λ)
  29. 29. Decrease Cycle Time• Less cycle time means more features out faster!• One way is to increase throughput• Another is to decrease WIP
  30. 30. Decrease Cycle Time• Less cycle time means more features out faster!• One way is to increase throughput• Another is to decrease WIP• We aim for 1.5-ish WIP cards per pair• http://www.limitedwipsociety.org
  31. 31. Retrospective• Weekly retrospective• Candid review of week• What did we do well, not so well, what should we try to improve on
  32. 32. CD Challenges?✓Determine Risk✓Project Management• Technical Challenges
  33. 33. Technical Challeges• Code Management• Continuous Integration• New Feature Management• Deployment
  34. 34. Twelve-Factor App• http://www.12factor.net• Codebase• Config• Dev/Prod Parity
  35. 35. Code Management• Twelve-Factor - One codebase (multiple is a system and not called an “app”)• (Environmental) Feature Toggles• Topic Branches
  36. 36. Continuous Integration• One integrated branch of code (to test and deploy)• Consensus and experience for feature toggles over complicated git strategies• http://www.infoq.com/interviews/jez- humble-martin-fowler-cd
  37. 37. Feature Toggle Challenges• Different toggle states per bin• “Pure”, unobtrusive feature toggles• Database migrations?
  38. 38. Env. Feature Toggles• Part of the config (twelve factor)• Should be expressed as env vars code_time.finally!
  39. 39. Dev/Prod Parity• Minimize Difference• Use the same stack locally that is used in development.• Persistence / backend services -- databases, queues, caching servers• Can be a challenge (e.g. Amazon AWS)
  40. 40. Brian Kaneybrian@vermonster.com“bkaney”, @bkaney, etc.Thanks!vermo nster

×