Continuous Delivery

928 views
846 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
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
928
On SlideShare
0
From Embeds
0
Number of Embeds
11
Actions
Shares
0
Downloads
10
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • 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

    ×