Hello , When implementing a trunk-based developmen...
# platform-culture
Hello , When implementing a trunk-based development approach with frequent deployments and feature flags, how do you ensure that code changes from different branches don't conflict with each other and cause issues during deployment?
How about if teams working on complex project choose either branch-per-feature approach or topic branches for smaller changes
Yeah, trunk-based development, in my experience, is almost always working on trunk and using FFlags to eliminate integration, especially for smaller changes. Bigger changes can work on trunk but require as a lot of care (aka energy) and so I do sometimes see bigger feature branches, but then you have to make sure to merge trunk into that branch very often, which has a whole other host of difficulties. In my experience, people then continue to just work the same way (pain in integration) but with the additional overhead of FF. So, uh, you kinda need to pick one, I think? FF is also a lot easier when you have a more service-oriented/modular approach because then someone working on some service somewhere can do a big refactor without impacting someone else...
If it's trunk based, there are no long-lived branches - the research suggests there is a tipping point if you have more than 3 branches, or if the branches live longer than a day. You can use keystoning, where you add code lower down first (so it can go to production, as it's not used) and then add successive layers. Only when you add the keystone (usually the UI, or a public API) do you expose the feature. You could work for a longer period with keystoning without making the feature available and without delaying integration to the main branch.
You can use feature toggles, where you inspect a toggle to see whether a feature should be available, or not. These toggles should be removed when "fully live". Or, you can use feature flags, which may represent more states than "on / off" and may be kept a little longer. You can use feature flags as part of you release strategy, the code going to production regularly but not shown to users yet. It also helps if you want to have canary users (they get the feature early) and for incident management (you could remove some services during an incident to reduce load, for example temporarily preventing your BIG EXPORT feature).