The Practices That Make Continuous Integration

Continuous Integration is by itself already a practice. It is one of the most critical practices to adopt to enable the fast flow of work through the value stream.

However, many teams believe Continuous Integration is just a tooling problem, to then pretend they practice Continuous Integration. Although they sometimes fail to do so and miss out on the benefits.

This session goes deeper into the practices that each on their own enable Continuous Integration. Learn how to gain fast feedback, increased stability and higher throughput!

Key takeaways:
- Be able to define what a state of Continuous Integration is
- Be able to enumerate the practices required to achieve Continuous Integration
- Be able to understand the practices

Transcript

1. @tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io @tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io The Practices That Make Continuous Integration Timid Thierry Ghent, Belgium On the left and back, Korenlei On the right and front, Graslei
2. @tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io Being vulnerable … I’m shy and introverted
3. @tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io
4. @tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io thinkinglabs.io everyone in the team commits at least once a day to Mainline every commit to Mainline triggers an automated build and execution of all automated tests whenever the build fails it gets fixed within 10 min Continuous Integration Test
5. @tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io Continuous Integration is a practice to ensure always working software and to get feedback within a few minutes to whether any given change broke the application. – Jez Humble
6. @tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io thinkinglabs.io 14 practices Team Working for CI Coding for CI Building for CI
7. @tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io Team Work for CI
8. @tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io
9. @tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io Without Version Control: • no single source of truth • hard to rollback a deployment
10. @tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io First practice that requires a tool!
11. @tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io Version Control System is a communication tool.
12. @tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io From now on, our code in revision control will always build successfully and pass its tests. – James Shore
13. @tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io It assumes … a comprehensive set of automated tests.
14. @tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io To satisfy this agreement …
15. @tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io Stop the line, fix immediately
16. @tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io The whole team owns the failure
17. @tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io Precondition to Continuous Integration Fix a broken build within 10 mins Otherwise … a whole team at stand still disables on-demand releases
18. @tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io Why 10 mins? because Have a Fast Build
19. @tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io Coding for CI
20. @tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io Break large changes in a series of small incremental changes => keep the application always working => never tearing the application apart
21. @tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io This is hard work!
22. @tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io Continuous Integration = integrate early and often
23. @tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io When not Committing Frequently • introduce batch work • integrating becomes time-consuming • prevents communication with the team
24. @tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io When Committing Frequently • changes are small • reduces risks • reverting a failing change is easier
25. @tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io Gentle design pressure to …
26. @tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io Only commit when the Local Build says SUCCESS => Test Driven Development
27. @tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io Small increments requires a decoupled codebase
28. @tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io • Ports & Adapters (aka Hexagonal Architecture) • Kent Beck's 4 rules of simple design • Intentional code duplication (see Expand & Contract) => improves quality => reduces engineering time
29. @tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io Strong enabler for Continuous Integration
30. @tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io
31. @tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io What if a feature takes too long to implement? => perfectly acceptable to have unfinished functionality in production
32. @tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io Feature Toggles enabler of Operability and Resilience but … comes with their fair share of problems
33. @tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io Building for CI
34. @tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io Build Script -> SUCCESS or FAILURE used by Local Build and Commit Build
35. @tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io Second and last practice that requires a tool!
36. @tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io Prevent broken build => run a Local private Build before committing
37. @tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io Commit to Mainline => triggers the Commit Build Monitor the Commit Build!
38. @tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io Gain confidence • enough automated tests • and of high-quality
39. @tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io Not enough tests = not enough feedback => cannot Commit Frequently
40. @tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io High Quality Automated Tests • Example Mapping • Right mix of roles in the team
41. @tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io Types of tests: • Unit Tests • Integration Tests • Automated Acceptance Tests • Smoke Tests
42. @tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io Commit Frequently => Fast Build
43. @tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io When the Build is slow • do not execute the Local Build • execute the Local Build less often
44. @tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io What is fast? • 10 min is the limit • under 5 min is the focus • 30s will avoid hallway sword fighting 🤷
45. @tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io Only two tools! • Version Control System • Automated build
46. @tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io
47. @tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io Where do we start?
48. @tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io The Improvement Kata
49. @tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io Continuous Integration together with trunk-based development predicts higher throughput and quality.
50. @tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io @tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io Hello, I am Thierry de Pauw Acknowledgments: Els, the one I love! Lisi Hocke (@lisihocke), Seb Rose (@sebrose) and Steve Smith (@SteveSmith_Tech) for their thorough reviews of the article series. Martin Van Aken (@martinvanaken), Martin Dürrmeier (@md42), Aki Salmi (@rinkkasatiainen), Nelis Boucke (@nelisboucke), Karel Bernolet (@BernoletKarel) for reviewing the slides. The folks at AlpesCraft for suggesting the use of the diagram as guiding principle. The article series: The Practices that make Continuous Integration https://thinkinglabs.io/the-practices-that-make-continuous-integration