Xp conf-tbd
Download as PPTX, PDF0 likes558 views
This document discusses different branching strategies for continuous delivery (CD), including traditional long and short lived feature branches as well as trunk-based development (TBD). It notes issues with traditional branching strategies and outlines how TBD works with all developers committing to a single branch. Feature toggles and branch by abstraction techniques are presented as ways to implement large features over multiple releases in a TBD workflow. Examples from Facebook and Google are provided that demonstrate how to scale TBD for large codebases.
Xp conf-tbd
- 1. Copyright © 2015 SolutionsIQ Inc. All rights reserved. Branching for CD? Think again ! Devesh Chanchlani
- 2. Self Introduction • Passionate Programmer • Technical Agile Coach with SolutionsIQ • Coach teams to embrace, scale and sustain XP practices • Belong to Pune
- 4. Long Lived Feature Branches 4 Less risk of non-finished changes » Merging with other Feature branches » Merging with mainline changes » Accommodating Refactorings and design improvements
- 5. 5 Changes being made to the mainline after being reviewed » Merging issues » Refactoring becomes challenging » Cannot have CI for each branch » Sometimes changes are big & individual commits not stable, that folks simply squash their changes into big commits. Short Lived Feature Branches D1 D2 D3 D4
- 7. <Footer Content: Presentation Title, Partner Name, Other> 7
- 8. 8 “Feature branching is a poor man's modular architecture, instead of building systems with the ability to easy swap in and out features at runtime / deploytime they couple themselves to the source control providing this mechanism through manual merging.” Dan Bodart
- 9. Trunk Based Development (TBD) <Footer Content: Presentation Title, Partner Name, Other> 9
- 10. What it means … All developers commit to a single branch, called trunk, making frequent check-ins. Branches are created only for Release purpose. Bugs are always fixed on trunk and then merged with release branch. Regular developers don’t commit to a release branch. Release branches are never merged back to trunk. Release branches are short-lived, frequently being replaced by other release branches. 10
- 11. 11 Trunk Based Development Strategies
- 12. 12 Imagine you are releasing into production every two weeks, but need to build a feature that's going to take three months to complete. How do you use Continuous Integration to keep everyone working on the mainline without revealing a half-implemented feature on your releases?
- 13. Feature Toggles 13 Courtesy: Spotify Labs / Henrik Kniberg
- 14. Feature Toggle implies … 14 A configuration file defines a bunch of toggles for various pending features. These toggles are mostly applied at UIs, from where interaction with the features begins. For features with no UI, the toggle will be in the app code. In such cases, techniques like polymorphic substitution and dependency injection should be used to avoid crude conditional tests. Feature toggles should be removed once the feature is complete. Pipelines for different permutations of toggles for releases should be setup. If either of the build fails, it implies a bad commit.
- 15. Feature Toggle types 15 1. Release – partial features, temporary 2. Business – certain class of users, permanent 3. Runtime – easier rollbacks, run tests with various configurations of features 4. Build – new feature codebase is not compiled
- 16. Branch by Abstraction 16 Consumer Component to be replaced STEP 1 Consumer Component to be replaced Abstraction Layer STEP 2 Consumer Old Component Abstraction Layer New Component STEP 3 Consumer Old Component Abstraction Layer New Component STEP 4
- 18. Facebook's Trunk Based Development 18
- 20. Google’s Scaled TBD 20 Deals with enormous codebase which changes at enormous speeds. Provides extensive tooling to the developers like Pre-commit validations formal integration/merge/commit itself have a “Distributed Builds” capability, which Supports “Caches” for leveraging results from previously built modules Uses “Gerrit“ for code reviews on refs/for/master branch. Has decided owners for all modules. Third party dependencies can have only one existing version in the trunk. Releases are made from branches cut from the trunk
- 22. What it takes to Deliver Continuously 22
- 23. References Paul Hammant - http://paulhammant.com Martin Fowler - http://martinfowler.com/bliki/FeatureToggle.html Carlos Lopes - Multiple projects, different goals, one thing in common: the codebase! Henrik Kniberg – Engineering at Spotify Chuck Rossi – The Facebook Release Process 23
- 24. Our Customers 24
Editor's Notes
- #7: Promiscuous Integration