AgileLINC Continous Slides by Daniel Harp
Download as PPTX, PDF0 likes400 views
This document discusses continuous integration practices. It defines continuous integration as an attitude rather than a tool. Key practices of continuous integration include: maintaining a single source repository, automating builds, keeping builds fast, making builds self-testing through automated tests, committing to the mainline daily to avoid branches, triggering a build on every commit through a build server, making every commit potentially shippable, ensuring binary integrity, testing in a clone of production, making the latest executable easily available, and enabling everyone to see what's happening. The document emphasizes focusing on organizational, architectural and process changes over tools when adopting continuous integration.
AgileLINC Continous Slides by Daniel Harp
- 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. Why Continuous Integration? “If you had a button that told you whether everything in the system was working, how often would you press it?”
- 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. 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. 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. 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. 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. 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. 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. X Branches Trunk Branch 1 Branch 2 What we tell ourselves branches look likeWhat branches actually look like… Branch 1 Branch 2
- 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. Branches Trunk If you insist on branching, merge often (daily)
- 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. 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. 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. Continuous Integration Key Practice #8: Binary Integrity Key Practice #9: Test in a clone of production
- 18. Continuous Integration Key Practice #10: Make it easy to get the latest executable Working software over comprehensive documentation
- 19. Continuous Integration Key Practice #11: Everyone can see what’s happening
- 20. Adopting Continuous Integration Focus changes on Organizational, Architectural & Process - not - Tools, Code, Infrastructure
- 21. Adopting Continuous Integration Get Measurable Change As Soon As Possible
- 22. Adopting Continuous Integration Create a culture of Continuous Improvement