@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

@tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io Being vulnerable … I’m shy and introverted

@tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io

@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

@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

@tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io thinkinglabs.io 14 practices Team Working for CI Coding for CI Building for CI

@tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io Team Work for CI

@tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io

@tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io Without Version Control: ● no single source of truth ● hard to rollback a deployment

@tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io First practice that requires a tool!

@tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io Version Control System is a communication tool.

@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

@tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io It assumes … a comprehensive set of automated tests.

@tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io To satisfy this agreement …

@tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io Stop the line, fix immediately

@tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io The whole team owns the failure

@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

@tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io Why 10 mins? because Have a Fast Build

@tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io Coding for CI

@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

@tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io This is hard work!

@tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io Continuous Integration = integrate early and often

@tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io When not Committing Frequently ● introduce batch work ● integrating becomes time-consuming ● prevents communication with the team

@tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io When Committing Frequently ● changes are small ● reduces risks ● reverting a failing change is easier

@tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io Gentle design pressure to …

@tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io Only commit when the Local Build says SUCCESS => Test Driven Development

@tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io Small increments requires a decoupled codebase

@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

@tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io Strong enabler for Continuous Integration

@tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io

@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

@tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io Feature Toggles enabler of Operability and Resilience but … comes with their fair share of problems

@tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io Building for CI

@tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io Build Script -> SUCCESS or FAILURE used by Local Build and Commit Build

@tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io Second and last practice that requires a tool!

@tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io Prevent broken build => run a Local private Build before committing

@tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io Commit to Mainline => triggers the Commit Build Monitor the Commit Build!

@tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io Gain confidence ● enough automated tests ● and of high-quality

@tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io Not enough tests = not enough feedback => cannot Commit Frequently

@tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io High Quality Automated Tests ● Example Mapping ● Right mix of roles in the team

@tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io Types of tests: ● Unit Tests ● Integration Tests ● Automated Acceptance Tests ● Smoke Tests

@tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io Commit Frequently => Fast Build

@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

@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 🤷

@tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io Only two tools! ● Version Control System ● Automated build

@tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io

@tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io Where do we start?

@tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io The Improvement Kata

@tdpauw@mastodon.social @tdpauw.bsky.social thinkinglabs.io Continuous Integration together with trunk-based development predicts higher throughput and quality.

@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