I always used Git Flow but I would like to try Tru...
# random
g
I always used Git Flow but I would like to try Trunk Based workflow. Has someone experiences with this type of work flow?
m
g
nice link!
m
I moved my org from gitflow to trunk-based a few years back. No regrets.
f
+1 Trunk based dev
l
In my experience, to convince a team to do TBD is one of the hardest thing to do
g
@Luca Carangella what are the reasons? It seems a simplier flow and it force you to make properly tests
l
I totally agree with you, but lots of people are still not familiar with it, and who is, usually thinks is more complicated to reason about. The biggest struggle is to breakdown the work in smaller chunks of work. It is easier for people to take a ticket and work on it for days, if not weeks without the extra work required to break things down. I didn't give up the idea just yet though ๐Ÿ™‚
d
Also interested if thereโ€™s a course available online that we could use
a
I'm transitioning my team as well to TBD. We are pretty small and people aren't exactly used yet, and more advanced concepts like abstraction based branching are out of reach at the moment, but until now everything is going smoothly. I also spent some time on a github action script that checks what branch you are pushing from. For example, the main branch deploys to the dev environment, feature branches deploy to a custom domain with the branch name but will use development environment backend (only on frontend at the moment as backend is not really viable financially in my opinion) and branches with
release/${production/staging}/${v1/v2/etc}
will deploy to staging/production respectively. There's still room to improve and I'm interested in how others are doing, but it's a starting point!
m
My suggestion is don't use release branches ever. It's pretty much antithetical to trunk-based development.
g
Its not too difficult, but you need a good feature flags system that everyone knows how to use.
in my experience, without a feature flags system, you cannot achieve the small commits / PRs necessary to do this.
l
Very good point @Gjorgji Kjosev, I agree 100%. Do you have a favourite one? I mean, do you have any feature flags system you would highly recommend?
g
I've had reasonable results with Unleash, but IDK if it fits a serverless workflow very well. Haven't used one for severless yet blush
m
I've been using LaunchDarkly for years. It's a very solid product that fits with a variety of architectures.
l
Thank you @Matt Morgan and @Gjorgji Kjosev. I do know them both, but I have direct little experience only with Unleash. I am glad to hear from you @Matt Morgan about your positive experience with LaunchDarkly because we are planning on investigating it. Thank you both for sharing
g
any experiences with AWS AppConfig? It supports feature toggle
a
@Matt Morgan hmm ok, how do you do it? I've followed the idea from trunkbaseddevelopment.com, where you push constantly on main and releases go on a release branch and any fixes are cherry picked from main if needed, but those branches shouldn't see any development activity per se
m
Why do you need release branches? Just deploy main.
I know you can do that, but why?
g
for us, we only really managed to stop using release branches when we started using feature flags for pretty much everything spanning > 1 PR
it seemed excessive at first but it quickly became natural
and, one of the best things about FF done right is that you can toggle them off immediately ๐Ÿ˜„
so the risk is actually smaller.
and another thing that might need getting used to / accounting for (at least for PMs) is that there will be work to remove the feature flag at some point
(that can probably be achieved by setting a maximum age or maximum number of active flags and the limits have to be respected before doing new features ๐Ÿ™‚)
oh and yeah. there will be code-path bifurcation that may look ugly. we had to accept that that's ok, as long as its correct ๐Ÿ˜„
(test bifurcation too, potentially. again - a good FF system needed ๐Ÿ˜„)