AgileLINC Continous Slides by Daniel Harp

305 views

Published on

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

  • Be the first to like this

No Downloads
Views
Total views
305
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

AgileLINC Continous Slides by Daniel Harp

  1. 1. Waterfall Integration Waterfall Integration Issues • Poor planning/design may require extensive redesign • Hard to predict how long it will take • Hard to determine how close you are to completing it • Easy for earlier project delays to cause Integration to start already behind schedule and be rushed • Defect root cause is hard to identify because of the large amount of changes
  2. 2. Why Continuous Integration? “If you had a button that told you whether everything in the system was working, how often would you press it?”
  3. 3. Agile/Scrum Integration
  4. 4. Continuous Integration Contrary to popular belief, continuous integration is an attitude, not a tool. --- James Shore, “The Art of Agile” Installing Jenkins ≠ Continuous Integration
  5. 5. Continuous Integration Key Practice #1: Maintain a single source repository Nobody Should Ever Ask, “Where’s the ____ properties file?” Store Everything Necessary to build your application • Source Code • Properties Files ** • Database Schemas • Install Scripts • Build Scripts • 3rd Party Libraries ** • … everything necessary to build your application … But do NOT include things you build… • Binaries (Executables, Jars, Wars…) • Generated Code (WSDL to Java…)
  6. 6. Continuous Integration Key Practice #2: Automate the Build Key Practice #3: Keep the Build Fast • General recommendation is less than 10 Minutes • Organize build steps to get critical feedback early • Push long running later in process or multi-thread It IS possible to do C.I. without automation, but why bother?
  7. 7. Continuous Integration Key Practice #4: Make the build self testing Compiled, Linked, Packaged … But does it “work”? Automated Testing is essential to Continuous Integration
  8. 8. Service Layer The Agile Testing Pyramid GUI QA Driven Developer Driven Test against binaries/ artifacts Test against Code - Mocked Dependencies Component Integration Tests Developer Driven Unit Tests are part of development. Code without unit tests should be treated the same as code that does not compile. Unit
  9. 9. Continuous Integration Key Practice #4: Make the build self testing Ensure that the code is tested • Code Coverage Tools • Commit to coverage percentage • Only represents execution, not test quality • Code Reviews • Pair Programming • Test First / Test Driven • UTDD (Unit TDD) • ATDD (Acceptance TDD) • BDD (Behavioral)
  10. 10. Continuous Integration Key Practice #5: Everyone commits to the mainline everyday • All new development should be done on the mainline (trunk) • Check in frequently, at least once a day • Avoid branches • “Feature Branching is a poor man’s modular architecture” -- Dan Bodart
  11. 11. X Branches Trunk Branch 1 Branch 2 What we tell ourselves branches look likeWhat branches actually look like… Branch 1 Branch 2
  12. 12. Branches Trunk Bug Fix Branch for Emergency fixes of released versions Release ReleaseRelease Release Bug Fix Branches should be short lived (or it probably wasn’t an “emergency”)
  13. 13. Branches Trunk If you insist on branching, merge often (daily)
  14. 14. Continuous Integration Key Practice #5: Everyone commits to the mainline everyday • All new development should be done on the mainline (trunk) • Check in frequently, at least once a day • Avoid branches • “Feature Branching is a poor man’s modular architecture” -- Dan Bodart Key ways to avoid branching: • Backwards compatibility • Feature Toggles
  15. 15. Continuous Integration Key Practice #6: Every commit should trigger a build on a build server • Scheduled builds (nightly) is not CONTINUOUS Integration • Builds on a build server ensure that the build isn’t tied to your local environment
  16. 16. Continuous Integration Key Practice #7: Every commit (& build) is potentially shippable • Don’t commit code with defects • (and remember, lack of tests is a defect) • Don’t commit new code on a broken build • Broken builds “Stop the line” • Don’t go home on a broken build
  17. 17. Continuous Integration Key Practice #8: Binary Integrity Key Practice #9: Test in a clone of production
  18. 18. Continuous Integration Key Practice #10: Make it easy to get the latest executable Working software over comprehensive documentation
  19. 19. Continuous Integration Key Practice #11: Everyone can see what’s happening
  20. 20. Adopting Continuous Integration Focus changes on Organizational, Architectural & Process - not - Tools, Code, Infrastructure
  21. 21. Adopting Continuous Integration Get Measurable Change As Soon As Possible
  22. 22. Adopting Continuous Integration Create a culture of Continuous Improvement

×