Make Development agile again

an alternative development process using feature-toggles instead of feature-branches

Transcript

1. Make Development Agile Again Robert Schönthal
2. THE CURRENT SITUATION
3. THE CURRENT SITUATION UAT PROD DEV
4. THE CURRENT SITUATION UAT PROD DEV
5. THE CURRENT SITUATION FEATUREFIX UAT PROD DEV
6. THE CURRENT SITUATION FEATUREFIX Merge in both directions! UAT PROD DEV
7. THE CURRENT SITUATION HOTFIX FEATUREFIX Merge in both directions! UAT PROD DEV
8. THE CURRENT SITUATION UAT PROD DEV HOTFIX FEATUREFIX Merge in both directions!
9. THE CURRENT SITUATION HOTFIX FEATUREFIX Merge in both directions! UAT PROD DEV
10. ➤ No idea, which Branch contains which Feature ➤ Lots of unnecessary Merge-Commits ➤ Big-Bang Merges of Features (all other work needs a rebase) ➤ Constant need to merge things between Branches ➤ Not really "Continuous" as in CI or CD ➤ Hard for new colleagues to grasp ➤ Frontend Branches needs to be in sync with the Backend Branches ➤ DB Migrations are a serious problem ➤ Lots of work to move Features, less time to Develop THE CURRENT SITUATION - PROBLEMS
11. A CASE STUDY
12. A CASE STUDY ➤ Big german company with a few billion € in revenue ➤ ~12 crossfunctional teams with ~10 people each ➤ decoupled self-contained Micro-Service Architecture ➤ each team owns parts of the website (PageAssembly in front) ➤ more than 3 UAT environments ➤ approx. 70 independent releases per day ➤ Fail-Forward strategy for bugs
13. A CASE STUDY ➤ each team deploys on their own ➤ massive concurrent development ➤ impossible to coordinate features ➤ you own it, break it, fix it ➤ impossible to know the state of 
 other components
14. ITS IMPOSSIBLE TO DEVELOP AT SCALE AND STAY SANE!
15. WHAT IF WE COULD REMOVE ALL THE FUZZ?
16. FEATURE TOGGLES TO THE RESCUE
17. ➤ make all aspects toggable (API/DB/JS/CSS) ➤ toggle only Features or Changes, Fixes are urgent anyways ➤ propagated to the Client-SPA via early api request ➤ they are basically just cookies in the frontend ➤ enable features for all, self or special users/ groups FEATURE TOGGLES - WHAT
18. JS EXAMPLE ➤ https://github.com/ willmendesneto/ngx- feature-toggle ➤ https://www.npmjs.com/ package/react-feature- toggles ➤ https://github.com/ bassdman/vue-feature- toggle ➤ must be immutable (so no one gains access to unreleased features) <toggle isActive="FOO"> <my-new-component/> </toggle> <toggle isInactive="FOO"> <my-old-component/> </toggle>
19. JAVA EXAMPLE ➤ https://www.togglz.org/ ➤ defacto standard for Java ➤ SpringBoot Integration ➤ different strategies for persisting toggle states (memory, DB, ...) <!-- pom.xml --> <dependency> <groupId>org.togglz</groupId> <artifactId>togglz-spring-boot-starter</artifactId> <version>2.6.1.Final</version> </dependency> <dependency> <groupId>org.togglz</groupId> <artifactId>togglz-console</artifactId> <version>2.6.1.Final</version> </dependency> <dependency> <groupId>org.togglz</groupId> <artifactId>togglz-spring-security</artifactId> <version>2.6.1.Final</version> </dependency> ;application.properties togglz.features.FOO.enabled=true togglz.features.BAR.enabled=false @Controller public class MyClass { private FeatureManager manager; public MyClass(FeatureManager manager) { this.manager = manager; } @RequestMapping("/") public ResponseEntity<?> index() { if (manager.isActive(FOO)) { // new code } else { // old code } } }
20. JAVA EXAMPLE
21. CSS EXAMPLE ➤ have an early JS hook which sets the body classes depending on the toggles <body class="FOO"> </body> .gallery { // toggle inactive } .FOO .gallery { // toggle active }
22. ➤ toggling DB State is the hardest ➤ generally write non-breakable migrations ➤ the old code should still work with the migration applied ➤ a additional table or field is no problem ➤ remove/rename fields/tables only once the feature-toggle for the code is removed (the feature is live) DB EXAMPLE
23. STITCHING IT TOGETHER ➤ Admin UI in the Backend (a passthru Page?) ➤ Authentication/ Authorization is handled by the Backend ➤ (Toggle) Admin can activate/deactivate toggles ➤ early XHR request fetches the current toggle state const fetchToggles = async () => { const res = await fetch('/toggles'); const toggles = await res.json(); // toggles for JS window.TOGGLES = Object.freeze(toggles); // toggles for CSS document.body.classList.add(...toggles .map(toggle => toggle.name) ); }
24. ➤ no Branch merging hassle ➤ only a master branch for all environments (all ENVs contain the same code) ➤ make small but consistent commits ➤ everybody gets everyone else changes quickly ➤ you can skip one UAT environment (DEV would be enough) ➤ real CI/CD as every commits lands on PROD ➤ DEV has all toggles active, PROD all inactive by default ➤ faster "time to delivery" of features (ship early, ship often) ➤ no DB Migration Problems FEATURE TOGGLES - PROS
25. ➤ for APPs only, for libraries its suitable to have a proper commit history and SemVer Releases ➤ no real Feature-Releases, instead a constant flow of features (good for customers) ➤ constantly shipping more code than needed (old & new) ➤ more Asset Invalidations -> Code-Splitting should be present ➤ a good Test-Suite should be present (Integration Tests) ➤ as proper reviewing is hard, its best to develop in pairs ➤ Reviews & Refactorings can be done afterwards ➤ some Features might be hard/impossible to toggle FEATURE TOGGLES - CONS
26. WITH A LITTLE BIT MORE CODE WE REDUCE PROCESS COMPLEXITY!
27. Thank You :) Make Development Agile Again