Trunk based development?
we are currently using Git flow strategy for pusing code in production. we have development, staging, production branch. we have multiple teams and working on different microservices.
Now we want to adopt trunk based development. but we have read few documents. but main concerns are:
1. How code review will work?
2. On which stage QA should test?
3. How feture flag works?
4. How code can be reverted, if feature does not work in production?
5. How versioning works?
2 Replies
There is a Microsoft nugget for feature flags https://learn.microsoft.com/en-us/azure/azure-app-configuration/use-feature-flags-dotnet-core?tabs=core6x never used so I can't attest how good or bad it is. I think there was a video or Talk by Nick Chapsas about that as well.
Tutorial for using feature flags in a .NET app
In this tutorial, you learn how to implement feature flags in .NET Core apps.
We follow a process where we commit to main, via feature branches, but that doesn't necessarily ship to prod; it's merely "ready"; and then we cut a broader release, which ships to prod, then potentially merge back, and tag the branch in main with the release version. I'm not a super fan; but we can't really ship faster.
This is somewhere between github flow and gitflow in my opinion.
Changing branching strategies is always a tough sell.
it changes the way teams work; and frankly, m(ost|any) devs suck balls at source control; so you're potentially stealing their productivity from their rote-driven actions to forcing a new worldview on them where they need a new set of rote-driven actions.
In particular ( opinion ) gitflow favors the idea of "rote-driven" source control actions, where you have devs that follow a very predefined process, and some experts that are able to take source control and produce higher level code promotions and manage release artifacts.