1. Understand
1.1. Problem
1.1.1. Multiple developpers
1.1.2. Many parallel "simple"code changes
1.1.2.1. Hard to prectict full impact
1.1.2.2. May be incompatible
1.1.3. Broken build
1.2. Solution
1.2.1. Continuous Integration CI
1.2.2. Principle
1.2.2.1. When
1.2.2.1.1. something is voracious in time and energy
1.2.2.2. Then
1.2.2.2.1. do it more frequently
1.2.2.3. So that
1.2.2.3.1. it forces you to make it less painfull
1.2.3. How
1.2.3.1. More frequently means
1.2.3.1.1. Split work in small batches
1.2.3.1.2. Build on each small change
1.2.4. Results
1.2.4.1. Improve sofware quality
1.2.4.1.1. Better bug catching / fixing
1.2.4.2. Reduce dev and maintenance cost
1.2.4.2.1. Less wast of time on complex merge / build
1.2.4.3. Improved team productivity
1.2.4.3.1. Motivation and time effectiveness
1.2.4.4. Reduce time to market
1.2.4.4.1. higher deployment frequency
1.3. Priority
1.3.1. CI is the top priority to implement Continuous Delivery
2. Measure
2.1. % of code commit resulting in build with NO manual action / all commints
2.2. % code commit triggering suite of test with NO manual action / all commits
2.3. % of (test + build) => succesfull in 1 day / all (test + build)
2.4. % of (acceptance + perf) tests => delivered to devs in 1 day / all (acceptance + perf) tests
2.5. % of builds available for explanatory test / all builds
2.6. Time to fix a broken builds at 90th percentile
3. Implement
3.1. Enablers
3.1.1. Work in small batches
3.1.2. Trunk based branch strategy
3.1.2.1. Merge at least daily
3.2. Timeline
3.2.1. Before each commit - push
3.2.1.1. Run set of local tests
3.2.1.1.1. types
3.2.1.1.2. Provide feedback in minutes
3.2.2. On commit + push at least once a day
3.2.2.1. Run set of automated tests
3.2.2.1.1. types
3.2.2.1.2. Provide feedback in minutes
3.2.2.2. Build the artifacts
3.2.2.2.1. Status visible to team
3.2.2.2.2. Do
3.2.2.2.3. Reapeatable
3.2.3. On merge / pull request update
3.2.3.1. Pause ongoing work to review code. test and build results rapidely
3.2.4. On merge /pull request approved
3.2.4.1. Same as "On commit + push": test + build
3.2.5. On failed test or broken build
3.2.5.1. Stop immediately ongoing work to fix bugs / tests
3.3. How many CI pipelines?
3.3.1. Two CI pipelines
3.3.1.1. What
3.3.1.1.1. Infra CI
3.3.1.1.2. App CI
3.3.1.2. Pros
3.3.1.2.1. Ease the move to trunkbase by limiting its scope: the App, not the infra
3.3.1.2.2. Speed up App test and build: less steps, less delays, different skills
3.3.1.3. Cons
3.3.1.3.1. Risk: A disjoint version scheme can Lead to painful rollback scenarios
3.3.2. Single CI pipeline
3.3.2.1. What
3.3.2.1.1. Infra and app steps in the same
3.3.2.2. Pros
3.3.2.2.1. Better consistency and syncrhonicity between Infra and App changes
3.3.2.2.2. No silos
3.3.2.3. Cons
3.3.2.3.1. Coupling all App and Infra change may reduce velocity
3.4. Where to run test?
3.4.1. Environment less
3.4.1.1. Unit
3.4.1.2. Code secu
3.4.1.3. Dependency analysis / upgrade
3.4.2. Environement required (dev, qa)
3.4.2.1. for integration test
3.4.2.1.1. Avoid mocking / consume real APIs
3.4.2.2. Segregated and provisioned on the fly
3.4.2.2.1. What
3.4.2.2.2. Pros
3.4.2.2.3. Cons
3.4.2.3. Shared
3.4.2.3.1. What
3.4.2.3.2. Pros
3.4.2.3.3. Cons
3.4.2.4. Hydrid
3.4.2.4.1. Shared by default, segreated when needed
3.4.2.4.2. Analyzed usage and prune is segregated not adopted
4. Pitfalls
4.1. Devs resistance to change to work in small steps
4.2. Weak CI foundations
4.2.1. aka, not putting everything into the code repository
4.3. Manual / partially automated build process
4.3.1. What is as code is documented by code
4.3.2. What is manual
4.3.2.1. leads to more errors
4.3.2.2. is not documented, or with obsolete doc
4.4. Missing fast test execution on each commit
4.4.1. Meaning
4.4.1.1. Missing test categorization by time to execute
4.4.1.2. That enable to execute often the short tests
4.5. Lack of priority to fix immediately broken builds
4.5.1. Meaning
4.5.1.1. Becomes quickly a blocker to truncbase dev