Introduction to Continuous Delivery

1,222 views
1,122 views

Published on

Published in: Technology, Business
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,222
On SlideShare
0
From Embeds
0
Number of Embeds
151
Actions
Shares
0
Downloads
54
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Introduction to Continuous Delivery

  1. 1. An Introduction to Continuous Delivery rolf russell continuous delivery practice lead© 2011 All rights reserved.
  2. 2. getting it in front of users quickly http://code.flickr.com
  3. 3. small feature chunks timeconstant flow of new features into productionincremental release of small changes
  4. 4. Why
  5. 5. build the right thing every business idea is a hypothesis until you get user feedback
  6. 6. corollary: don’t waste money on the wrong thingStandish Group: how often features are used Never 45% Rarely 19%Sometimes 16% Often 13% Always 7%
  7. 7. constant user connectionby releasing everyday: your users can be delighted by new stuff all the time your users get the feeling you are reacting to what they want
  8. 8. ability to move quicklyreact to the marketexplore new revenue streams
  9. 9. better aligned peopledevelopment & operations close to the businessIT no longer perceived asthe bottleneck
  10. 10. reliability & stability John Allspaw: “Ops Metametrics” http://slidesha.re/dsSZIr
  11. 11. TTR (time to recover) time to figure time to out cause of >> fix problem problem time uh oh wheeew problem happens problem solved adapted from John Allspaw
  12. 12. progress
  13. 13. How
  14. 14. fast, automated feedback on theproduction readiness of your applicationsevery time there is a changewhether code, infrastructure, configuration or database Jez Humble
  15. 15. continuous delivery small feature chunks timesoftware always production ready releases tied to business needs, not IT constraintsminimize the lead time from idea to live concept to cash
  16. 16. systems thinking is [a philosophy] based on thebelief that the component parts of a system can bestbe understood in the context of relationships witheach other and with other systems, rather than inisolation.
  17. 17. value stream mappingprocess tool for improving the flow from a customer request to the fulfillment (concept to cash)emphasis is on improving the whole not just the partsuses quantitative data to identify waste and inefficiencyoriginally developed by toyota to assist in the improvement of manufacturing and supply-chain processes
  18. 18. value stream mapping requirement requirement coding automated integration uat release discovery definition testing testinglead-time 4 wks 4 wks 6 wks 1 wk 4 wks 1 wk 1wkvalue-add-time 2 days 1 wk 4 wks 2 days 1 wk 1 day 4 hrscomplete &accurate 30% 50% 25% 40% 80% 90% 80%
  19. 19. value stream mapping requirement requirement coding automated integration uat release discovery definition testing testinglead-time 4 wks 4 wks 6 wks 1 wk 4 wks 1 wk 1wkvalue-add-time 2 days 1 wk 4 wks 2 days 1 wk 1 day 4 hrscomplete &accurate 60% 50% 25% 40% 80% 90% 80%
  20. 20. while (true) { if (change checked into vcs) then build & test sleep 60}
  21. 21. step 1 - continuous integration
  22. 22. n tio uc od Pr nt me y plo De off - gn Si n ru y Dr g stin te n sio se es lea ild gr Re Re bu faster feedback nt me n g ple lanni Im p ng stifull production pipeline te al anu d M ate sts tom Te Au ional t nc Fu w slo CI t fas CI -* - in e ck Ch ,*-.$#/#*+/ !"#$%&($ ld bui e r lop ve De ff -o ck ki +&% ion
  23. 23. full production pipelineautomated implementation of your system’s build, deploy, test, approval processes!   visibility!   traceability!   compliance
  24. 24. treat everything like codecheck in, automate, test in CI, promote in deployment pipeline•  database: DDL & static data•  deployment automation•  infrastructure/configuration mgmt•  monitoring configuration
  25. 25. treat servers like cattle, not pets
  26. 26. adhere to the test pyramid Adapted from Mike Cohn (Automated Test Pyramid) and Lisa Crispin & Janet Gregory (Agile Testing)
  27. 27. trunk based development Professor Plum P1 P2 P3 P4 P4 P1 P2 P3 P4 P5 P1 P3 P4 P5 P2 B2 G3 G1 B1 G2 Mainline B1 B2 B1 B2 P4-5 G1 P1-2 G2 P3 G3 G4 G5 G6 G1 G2 G3 G4 G5 G6 Reverend Green G3 G4 G2 branches discourage refactoring branches delay integration and hide risk merging wastes time and is tedious
  28. 28. trunk based developmentfeature toggles let you deploy incomplete featuresturned offbranch-by-abstraction lets you make architecturalchanges
  29. 29. consistency from development to production accidental >> necessary inconsistency inconsistency deployment process environment configuration testing tools
  30. 30. pull itops onto the delivery teamsit together: biz, dev, qa & sysadminshare KPIs for stability and changesame story wall and iterations
  31. 31. “in production”? “live”?what does “in production” mean today?what does “live” mean? is it a binary state?how can we take advantage of shades of grey in “live”?
  32. 32. concernsreliability & stabilitycompliance & traceabilityreleasing 10 times/day •  don’t need to, just keep your code always production releasablecomplexity of my systems •  its about continuous improvement. start with low hanging fruitit will take investment •  yes it will, but it will also start paying dividends quickly
  33. 33. homework how long would it take to get a one line code change into production using the normal process? Mary & Tom Poppendieck Implementing Lean Software Development
  34. 34. Q&A
  35. 35. Thank you!
  36. 36. extra credit: lean startup movementapproach to managing disruptive innovationgoal of startups is to learn •  true for everyone early in the innovation cyclelearning should not be adhoc •  be rigorous & use the scientific method •  hypothesis -> experiment -> analysis

×