Slide 1

Slide 1 text

@[email protected] @tdpauw.bsky.social thinkinglabs.io @[email protected] @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

Slide 2

Slide 2 text

@[email protected] @tdpauw.bsky.social thinkinglabs.io Being vulnerable … I’m shy and introverted

Slide 3

Slide 3 text

@[email protected] @tdpauw.bsky.social thinkinglabs.io

Slide 4

Slide 4 text

@[email protected] @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

Slide 5

Slide 5 text

@[email protected] @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

Slide 6

Slide 6 text

@[email protected] @tdpauw.bsky.social thinkinglabs.io thinkinglabs.io 14 practices Team Working for CI Coding for CI Building for CI

Slide 7

Slide 7 text

@[email protected] @tdpauw.bsky.social thinkinglabs.io Team Work for CI

Slide 8

Slide 8 text

@[email protected] @tdpauw.bsky.social thinkinglabs.io

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

@[email protected] @tdpauw.bsky.social thinkinglabs.io First practice that requires a tool!

Slide 11

Slide 11 text

@[email protected] @tdpauw.bsky.social thinkinglabs.io Version Control System is a communication tool.

Slide 12

Slide 12 text

@[email protected] @tdpauw.bsky.social thinkinglabs.io From now on, our code in revision control will always build successfully and pass its tests. – James Shore

Slide 13

Slide 13 text

@[email protected] @tdpauw.bsky.social thinkinglabs.io It assumes … a comprehensive set of automated tests.

Slide 14

Slide 14 text

@[email protected] @tdpauw.bsky.social thinkinglabs.io To satisfy this agreement …

Slide 15

Slide 15 text

@[email protected] @tdpauw.bsky.social thinkinglabs.io Stop the line, fix immediately

Slide 16

Slide 16 text

@[email protected] @tdpauw.bsky.social thinkinglabs.io The whole team owns the failure

Slide 17

Slide 17 text

@[email protected] @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

Slide 18

Slide 18 text

@[email protected] @tdpauw.bsky.social thinkinglabs.io Why 10 mins? because Have a Fast Build

Slide 19

Slide 19 text

@[email protected] @tdpauw.bsky.social thinkinglabs.io Coding for CI

Slide 20

Slide 20 text

@[email protected] @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

Slide 21

Slide 21 text

@[email protected] @tdpauw.bsky.social thinkinglabs.io This is hard work!

Slide 22

Slide 22 text

@[email protected] @tdpauw.bsky.social thinkinglabs.io Continuous Integration = integrate early and often

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

@[email protected] @tdpauw.bsky.social thinkinglabs.io Gentle design pressure to …

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

@[email protected] @tdpauw.bsky.social thinkinglabs.io Small increments requires a decoupled codebase

Slide 28

Slide 28 text

@[email protected] @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

Slide 29

Slide 29 text

@[email protected] @tdpauw.bsky.social thinkinglabs.io Strong enabler for Continuous Integration

Slide 30

Slide 30 text

@[email protected] @tdpauw.bsky.social thinkinglabs.io

Slide 31

Slide 31 text

@[email protected] @tdpauw.bsky.social thinkinglabs.io What if a feature takes too long to implement? => perfectly acceptable to have unfinished functionality in production

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

@[email protected] @tdpauw.bsky.social thinkinglabs.io Building for CI

Slide 34

Slide 34 text

@[email protected] @tdpauw.bsky.social thinkinglabs.io Build Script -> SUCCESS or FAILURE used by Local Build and Commit Build

Slide 35

Slide 35 text

@[email protected] @tdpauw.bsky.social thinkinglabs.io Second and last practice that requires a tool!

Slide 36

Slide 36 text

@[email protected] @tdpauw.bsky.social thinkinglabs.io Prevent broken build => run a Local private Build before committing

Slide 37

Slide 37 text

@[email protected] @tdpauw.bsky.social thinkinglabs.io Commit to Mainline => triggers the Commit Build Monitor the Commit Build!

Slide 38

Slide 38 text

@[email protected] @tdpauw.bsky.social thinkinglabs.io Gain confidence ● enough automated tests ● and of high-quality

Slide 39

Slide 39 text

@[email protected] @tdpauw.bsky.social thinkinglabs.io Not enough tests = not enough feedback => cannot Commit Frequently

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

@[email protected] @tdpauw.bsky.social thinkinglabs.io Types of tests: ● Unit Tests ● Integration Tests ● Automated Acceptance Tests ● Smoke Tests

Slide 42

Slide 42 text

@[email protected] @tdpauw.bsky.social thinkinglabs.io Commit Frequently => Fast Build

Slide 43

Slide 43 text

@[email protected] @tdpauw.bsky.social thinkinglabs.io When the Build is slow ● do not execute the Local Build ● execute the Local Build less often

Slide 44

Slide 44 text

@[email protected] @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 🤷

Slide 45

Slide 45 text

@[email protected] @tdpauw.bsky.social thinkinglabs.io Only two tools! ● Version Control System ● Automated build

Slide 46

Slide 46 text

@[email protected] @tdpauw.bsky.social thinkinglabs.io

Slide 47

Slide 47 text

@[email protected] @tdpauw.bsky.social thinkinglabs.io Where do we start?

Slide 48

Slide 48 text

@[email protected] @tdpauw.bsky.social thinkinglabs.io The Improvement Kata

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

@[email protected] @tdpauw.bsky.social thinkinglabs.io @[email protected] @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