Continuous Integration with Trunk-based and Feature toggle (JomLaunch Edition)

Transcript

1. Continuous Integration with Trunk-based & Feature Toggle @aziziyazit
2. Who am i? Azizi Yazit UI Developer, FE Architect & Speaker Self-taught Historian (new narrative)
3. UI Developer SPA SPA SPA Lib Monorepo Module Federation Lib Lib
4. FE Architect SaSS-BEM Design System Component Library Atomic Design State Management Modular Monolith MicroFE Trunk Based GitFlow CI, CD
5. Speaker
6. 2 ways of building the feature Time-box Continuous
7. Time-box Integration Feature A 2d 3d 2d 4d 2d 13d Feature B 3d 4d 3d 4d 2d 16d Feature C 2d 3d 2d 4d 2d 13d
8. Time-box Integration Feature A (13d) 120 files changes 30 new files 10 deleted files 10 conflicted files Feature B Feature C
9. Integration Diagram Feature branch Mainline branch commit mainline commit checkout pulling merge integration flow
10. Feature A Feature B Feature C Mainline Time-box Integration 2d 3d 2d 4d 2d
11. Feature A Feature B Feature C Mainline Time-box Integration merge hell conflicts pull latest code to the dev branch
12. Feature A Feature B Feature C Mainline 2d 3d 2d 4d 2d Time-box Integration 80 files changes 4 deleted files 5 conflicted files 20 new files merge hell!
13. Feature A Feature B Feature C Mainline 2d 3d 2d 4d 2d Time-box Integration huge PR
14. Feature A Feature B Feature C Mainline 2d 3d 2d 4d 2d Time-box Integration merge hell! 2x merge hell!
15. Feature A Feature B Feature C Mainline 2d 3d 2d 4d 2d Time-box Integration 2x huge PR Code freeze for intensive testing
16. Time-box Integration Pros Cons • Merge hell • Delay on testing • Delay on feedback • Heavy cognitive load • Delay on release • Isolated code changes • Works independently
17. Continuous Integration (CI) CI is a software development practice where: • Integrate frequently (at least daily). • Each integration is verified by an automated build & test to detect integration errors as quickly as possible. • Significantly reduced integration problems. • Allows a team to develop cohesive software more rapidly. • Most popular branching policy for CI is trunk-based development. martinfowler.com
18. Continuous Integration (CI) Developers integrate all their work into trunk (also known as mainline or master) on a regular basis (at least daily). @jezhumble
19. • Branching policy for CI. • Key enabler for CI. Trunk-based Development: State of DevOps 2021 Continuous Integration (CI) Trunk-based Development
20. • Branching policy for CI. short-lived branch branch-by-abstraction feature-toggle fix-forward • Key enabler for CI. Trunk-based Development: Continuous Integration (CI) Trunk-based Development
21. Who are here doing the Continuous Integration? Continuous Integration (CI)
22. Continuous Integration (CI) 1 2 3 JEZ Humble & Martin Fowler Every developer commits at least daily to shared mainline Every commit triggers an automated build & test If build & test fails, it’s repaired within 10 mins
23. Continuous Integration (CI) illusion of practising continuous integration CI theatre
24. Feature A Feature B Feature C Continuous Integration (CI) 3h 5h 4h 4h 3h 3h 3h 3h 8h 8h 2 PR’s / day 4 PR’s / day 1 PR / day + + 7 Integrate Build Test
25. Feature A - 1st PR 3 files changes 5 new files 1 deleted files 0 conflicted files Feature B Feature C Continuous Integration (CI)
26. short-lived branch Mainline short-lived branch Continuous Integration (CI) short-lived branch 2h 2h 4h on demand release automated build & test build or test failed Trunk-based Development: Short-lived branch
27. Mainline short-lived branch short-lived branch 2h 2h 4h on demand release automated build & test build or test failed Continuous Integration (CI) Trunk-based Development: Short-lived branch short-lived branch ‣ A short-lived branch is something that should last 1 or 2 days max and carry a consistent piece of code that contributes to the feature you are building.
28. Mainline short-lived branch short-lived branch 2h 2h 4h on demand release automated build & test build or test failed short-lived branch Continuous Integration (CI) Trunk-based Development: Short-lived branch create PR Build PR ready Approve PR Build integrated into mainline
29. Mainline short-lived branch short-lived branch 2h 2h 4h on demand release automated build & test build or test failed short-lived branch 3 files changes 1 deleted files 0 conflicted files 5 new files Continuous Integration (CI) Trunk-based Development: Short-lived branch A few minutes for the review is best, and tens of minutes acceptable. More than a hour or two, and you are negatively affecting cycle times.
30. 1 deleted files 0 conflicted files 3 files changes 5 new files Benefits • NO Merge hell • NO code freeze • Continuous code review • Continuous feedback • Low cognitive load • On demand release Continuous Integration (CI)
31. short-lived branch Mainline short-lived branch 2h 2h 4h automated build & test Continuous Integration (CI) 1h 2h build or test failed
32. short-lived branch Mainline short-lived branch automated build & test build or test failed Continuous Integration (CI) 2h 2h 4h 1h 2h hour-based efforts
33. short-lived branch Mainline short-lived branch 2h 2h 4h automated build & test 1h 2h build or test failed Continuous Integration (CI) unsuccessful build prevent integration to the mainline
34. short-lived branch Mainline short-lived branch 2h 2h 4h automated build & test 1h 2h build or test failed 10m or <1h review Continuous Integration (CI)
35. Benefits • NO Merge hell • NO code freeze • Continuous code review • Continuous feedback • Low cognitive load • On demand release feature toggle on off Continuous Integration (CI) Trunk-based Development: Feature-toggle
36. short-lived branch Mainline short-lived branch v2 day 1 day 2 v1 toggle off toggle on release to prod Continuous Integration (CI) Trunk-based Development: Feature-toggle
37. short-lived branch Mainline short-lived branch v2 day 1 day 2 toggle on Continuous Integration (CI) Trunk-based Development: Feature-toggle v1 toggle off release to prod integrate incomplete code safely release anytime dev team always have latest codes
38. short-lived branch Mainline short-lived branch day 1 day 2 v1 toggle off Continuous Integration (CI) Trunk-based Development: Feature-toggle v2 toggle on release to prod • once the feature is completed & tested, we will toggle it to the user • if the feature got issue on prod, it’s easily toggled back to hide
39. Continuous Integration (CI) Trunk-based Development: Feature-toggle
40. Continuous Integration (CI) Trunk-based Development: Feature-toggle <div *featureFlag=“‘duitnow’”> </div> <div *featureFlag=“‘fpx’”> </div> Duitnow payment FPX { “duitnow”: true, “fpx”: false }
41. Benefits • NO Merge hell • NO code freeze • Continuous code review • Continuous feedback • Low cognitive load • On demand release Buttons 3 files Textfield 3 files header 2 files integration 1 files Continuous Integration (CI) Trunk-based Development: Branch-by-abstraction
42. short-lived branch Mainline buttons 20% textfield 20% code review Continuous Integration (CI) Trunk-based Development: Branch-by-abstraction buttons textfield
43. short-lived branch Mainline textfield 20% textfield Continuous Integration (CI) Trunk-based Development: Branch-by-abstraction buttons 20% code review buttons divide the branches into abstractions reviewer will get familiar with the code little by little. This help to get the full context about the code
44. Benefits • NO Merge hell • NO code freeze • Continuous testing • Continuous feedback • Low cognitive load • On demand release feedback on code feedback on build & test feedback from testing feedback from business feedback on product Continuous Integration (CI)
45. Benefits • NO Merge hell • NO code freeze • Continuous testing • Continuous feedback • Low cognitive load • On demand release code review Continuous Integration (CI) 1 2 3 4 5 code build & test Cognitive load refers to the amount of information the working memory can hold at any one given time. Most people can handle a cognitive load of between 3 and 7 separate pieces of information.
46. Benefits • NO Merge hell • NO code freeze • Continuous testing • Continuous feedback • Low cognitive load • On demand release Continuous Integration (CI) Codebase is always maintained in a releasable state.
47. Continuous Integration (CI) Summary • Continuous Integration means the team knows what the current state of the code truly is, we avoid big risky merges, and people can refactor as much as they need to. • Trunk-based Development (TBD) is the key enabler for the CI. We should implement these two technical practices concurrently, because they have more impact when you use them together. • Feature Toggles are a powerful technique, allowing teams to modify system behaviour without changing code.
48. Continuous Integration (CI) Bibliography • https://martinfowler.com/bliki/ContinuousIntegrationCertification.html • https://martinfowler.com/articles/continuousIntegration.html • https://www.gocd.org/2017/05/16/its-not-CI-its-CI-theatre/ • https://trunkbaseddevelopment.com/ • https://martinfowler.com/articles/feature-toggles.html • https://martinfowler.com/articles/branching-patterns.html • https://martinfowler.com/bliki/BranchByAbstraction.html • Continuous Integration Improving Software Quality and Reducing Risk book • Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations book • Team Topologies book • Monolith to Microservice (feature toggle & branch-by-abstraction section) book • Design It book • https://www.youtube.com/c/ContinuousDelivery • Jez Humble youtube videos