Ben Reich - Continuous Integration Best Practices in Agile Environments

6,132 views

Published on

1 Comment
3 Likes
Statistics
Notes
  • Does anyone know of a good tool review for CI tools? A company called cloudbees [https://www.cloudbees.com] offers a hosted solution for Jenkins. Travis CI is out there as well. Anyway, I am asking, because I see Jenkins around a lot and CloudBees around some and am looking for a good head-to-head comparison against other tools.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
6,132
On SlideShare
0
From Embeds
0
Number of Embeds
368
Actions
Shares
0
Downloads
136
Comments
1
Likes
3
Embeds 0
No embeds

No notes for slide

Ben Reich - Continuous Integration Best Practices in Agile Environments

  1. 1. Continuous Integration Best Practices in Agile Environments<br />Ben Reich @ AgileSparks<br />
  2. 2. Who Am I?<br />15 years leadership experience in software development & startup operations with Gantt charts<br />7 Years of searching and finding ways to improve life quality, predictability and efficiency<br />www.linkedin.com/in/benreich<br />E-mail: ben@agilesparks.com<br />
  3. 3. Ideas and best practices on implementing continuous integration in an agile way<br />What is this about?<br />
  4. 4. Continuous Integration 101<br />Code<br />Repository<br />Production Clone <br />Build<br />Change<br />Build<br />Auto<br />Builder<br />Publish<br />Feedback<br /><ul><li>Small and Frequent changes
  5. 5. Fast and immediate build
  6. 6. Immediate feedback</li></ul>Auto<br />Test<br />
  7. 7. So, why is it agile?<br />Rapid<br />Delivery<br />Small <br />Iterations<br />Continuous<br />Integration<br />Working<br />Software<br />Encourage<br />Cooperation<br />
  8. 8. But: Is a bunch of programmers constantly mixing some code together really getting us where we want to be?<br />
  9. 9. The Challenges of CI<br />Distance from the end user<br />Automatic tests are difficult<br />Large and complex products<br />Diverse organization<br />Insufficient review<br />Inter-team synchronization issues<br />
  10. 10. You know its becoming irrelevant if:<br />Nobody is consuming it and people are waiting for your “real release”<br />
  11. 11. Escaped bugs<br />Instant Response<br />What Happens here?<br />And here?<br />
  12. 12.
  13. 13. “Holy Place” Culture – Done means Released<br />Identify the “holy place”<br />Designated delivery target<br />Always up and running<br />As Releasable as possible<br />Replica of Production<br />Demo-able and accessible<br />Identify the Stakeholder<br />Represents the customer<br />Is motivated to succeed<br />Can deliver UAT<br />Has the bandwidth to review<br />
  14. 14. Put it where its accessible, demoable, won’t break but will be updated regularly in days <br />
  15. 15. The Delivery Gap<br />Manual testing takes longer and there is no synchronization<br />Developers need to program before testers need to test<br />Large projects need constant integration testing<br />Too many changes can disrupt the flow<br />
  16. 16. Ingredients to Fill the GAP<br />Time Box<br />WIP Limits<br />Agile Communication<br />
  17. 17. Case Study – The Demo Cycle<br />8 man team<br />1 month sprint<br />1 week demo cycle<br />1 week deployment cycle<br />Typically 2-4 user stories deployed per week<br />
  18. 18. The Continuous Delivery Train Station Cycle<br />Integration Area<br />Holy Place<br />Team<br />Branch<br />Weekly<br />Branch<br />The Holy Trunk<br />Commits<br />Tests<br />?<br />Deploy<br />Branch<br />Updated<br />Weekly<br />Branch<br />Commits<br />Tests<br />Deploy<br />
  19. 19. The Continuous Delivery Train Station Cycle<br />Integration Area<br />Holy Place<br />Team<br />Branch<br />Weekly<br />Branch<br />The Holy Trunk<br />Commits<br />Tests<br />?<br />X<br />Reject<br />Whew!!<br />Branch<br />Last Good<br />Branch<br />Commits<br />Tests<br />Deploy<br />
  20. 20. The Continuous Delivery Train Station Cycle<br />Integration Area<br />Holy Place<br />Team<br />Branch<br />Weekly<br />Branch<br />The Holy Trunk<br />Commits<br />Tests<br />?<br />X<br />Reject<br />Branch<br />Last Good<br />Branch<br />Commits<br />Tests<br />X<br />Reject<br />
  21. 21.
  22. 22.
  23. 23. Swarm!!<br />
  24. 24. Electronic WIP dashboard<br />
  25. 25. Large Projects - Scrum of Scrum<br />Frequency – 1 to 3 days<br />What is discussed?<br />What has your team done since we last met?<br />What will your team do before we meet again?<br />Is anything slowing your team down or getting in their way?<br />Are you about to put something in another team’s way?<br />The last two items will feature:<br />Broken APIs<br />Synchronization issues<br />Current build status<br />Story and Epic issues<br />
  26. 26. Working with Large Remote Teams<br />jQuery<br />Linux<br />Is it Impossible?<br />rails<br />django<br />Python<br />
  27. 27. Learning from Open Source<br />Manage by committee<br />Dedicate resources to CI<br />Set strict rules and enforce them<br />Enforce and encourage communication<br />Never go home with a broken build<br />
  28. 28. Rules of engagement - Example<br />
  29. 29. Github Change log – Social coding<br />
  30. 30. Source Control Management Recipes<br />Quiz - Which Tree Looks More Target Oriented?<br />Eshel<br />Brosh<br />1 trunk – No Deviations<br />
  31. 31. Incremental changes <br />Feat. 1<br />Rev 3<br />Rev 2<br />Main Trunk<br />Rev 1<br />Feat. 1<br />Rev 3<br /><ul><li>Rule no. 1 – Do not branch for features.
  32. 32. Rule no. 2 – If you breached Rule no. 1:
  33. 33. Merge quickly – Put an expiration date on branches
  34. 34. Only one level
  35. 35. Police the branches
  36. 36. Pull Trunk before merging
  37. 37. Test branches before merging</li></li></ul><li>Hiding New Features<br />Not usually recommended<br />Better than Branching<br />Gradual integration<br />Passes some tests<br />Lower Stabilization Cost<br />
  38. 38. Branching by Abstraction<br />Logic Functionality<br />Spaghetti<br />Persistence Functionality<br />
  39. 39. Branching by Abstraction<br />Abstraction<br />
  40. 40. Branching by Abstraction<br />Replacement<br />Old Layer<br />New Layer<br />
  41. 41. Branching by Abstraction<br />Replacement<br />
  42. 42. Auto testing – The Key to Success<br />Automate in order<br />Automate the happy path first<br />Maximize coverage with data and not complex scripting<br />Look for repeating manual tests<br />Spec test together with PO<br />Automate when functionality is frozen<br />
  43. 43. What Next?<br />Visualize your value stream<br />Choose tools<br />Continuous Integration<br />Auto testing<br />Deployment<br />Invest in automatic testing<br />Tailor fit a process to your needs<br />
  44. 44. Questions?<br />Thank You!<br />www.linkedin.com/in/benreich<br />E-mail: ben@agilesparks.com<br />

×