How to transition a team from Git-flow to trunk/CI-CD?

7 points by chuie 3y ago ↗ HN

Hi all, this is my first job in a management position and I am feeling quite a bit of impostor syndrome, so I'd really love to get extra eyes on a plan to transition a team that uses git-flow with a weekly release cadence to transition to trunk and eventually ci/cd.

First, there are regular problems that occur in and around releases, so this isn't busy work, some form of intervention is necessary, and because managing branch hell is part of the problem and something that git-flow is known for, moving to automation with continuous release sounds like a reasonable step.

So my current plan is:

Step 1: Keep current release schedule, but treat develop as if it were main. Add feature flags and minimum daily commit to develop.

Step 2: Add CI/CD pipeline to non-live deployment, like blue green deployment.

Step 3: Add unit/integration test gates to deployment of step 2.

Step 4: Stay in holding pastern for few weeks to deal with any emergent problems, testing failures, etc

Step 5: Migrate fully to trunk based. Eliminate develop.

Any thoughts, criticisms, feedback?

5 comments

[ 3.4 ms ] story [ 20.7 ms ] thread

kostarelo 3y ago ↗

I see you have a good suggestion but I haven’t really got what the problem is. Is it the weekly release cadence, you mentioned branch hell but tbh I’m not familiar with it, how does it look like? What are the biggest pain points?

I’m only trying to make sure I understand the problem otherwise I cannot evaluate the solution. Plus it would have make it very hard to sell it to me, if I was to take the decision.

chuie 3y ago ↗

Id say every 3rd deployment or so, especially when new features are added, there is a lot of stress around cutting a release and deploying. People on the team become extra scrutinous of people who break the release build or don't have the features completed, or havent submitted enough tickets. Which, as a manager I appreciate the peer pressure, but I doubt the stress is good for moral of the members who are on the receiving end of it and I think the same feedback without the urgency behind it would be pedagogically more valuable.

Second, when a release is made and a bug is found there are branches mad from main (not develop) to fix the bugs, that must then be merged into develop (referred to as a merge-back) which increases surface area for errors as well as more time spend untangling the emerging web of branches. Now, in the hands of a capable engineer this isnt a massive lift, but also there are processes to automate all of this and that capability would be better spent day dreaming about a side project as far as I am concerned.

Have I persuaded you?

vipull 3y ago ↗

Here’s a process that worked well for us back when I was a manager managing a largeish devteam.. we cut a release every week, and the bug fixes would go into a branch cut from the release branch, merged back into main after the release (well-tested) We had a lot of manual QA so we never got to experiment with automated frameworks like cypress (jobs for aa people were important so automated testing was never a priority..:)!

We never experimented with ci/cd but that was done to avoid overhead..

So here’s the branch layout: main branch(always releasable), develop (into which personal dev branches/feature branches are merged), and then we had release branches. No automation of any kind but this is India and we had a lot of manual labor and manpower at disposal. YMMV so take my advice with a pinch of salt.

I’d say keep the git-flow but structure things differently. git-flow has a lot of modern benefits!

cweagans 3y ago ↗

Do not specify this plan in such detail. If your role is management, you need to think in terms of objectives, clearly communicate those objectives, and allow the engineers space and autonomy to meet those objectives.

Try “we need to ship more frequently (with the end goal being CI/CD) because our releases cause problems all the time and it’s very expensive” or something along those lines. Ask the engineers on your team to determine an approach that works for them, run it by you (your job in this is to manage risk/timeline/cost, not get them to do it your specific way), and then do it.

brownfox 3y ago ↗

I'm not sure what you're trying to accomplish, but having some goals is better than having none. If implementing CI/CD is important for your team, then make it a priority. Your role is to determine the direction, allocate resources, oversee the entire process, and evaluate the results.

However, it's important to discuss and collaborate on the decision-making, planning, and execution process during team meetings. Avoid making unilateral decisions and imposing workloads on others.

Initiate the discussion by acknowledging a common issue that affects workflow and asking for input from the team on how to address it and what improvements would be beneficial. Encourage the team to contribute to finding a solution.