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.<p>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.<p>So my current plan is:<p>Step 1: Keep current release schedule, but treat develop as if it were main. Add feature flags and minimum daily commit to develop.<p>Step 2: Add CI/CD pipeline to non-live deployment, like blue green deployment.<p>Step 3: Add unit/integration test gates to deployment of step 2.<p>Step 4: Stay in holding pastern for few weeks to deal with any emergent problems, testing failures, etc<p>Step 5: Migrate fully to trunk based. Eliminate develop.<p>Any thoughts, criticisms, feedback?
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.<p>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 <i>them</i>, 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.
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?<p>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.
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.<p>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.<p>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.
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..:)!<p>We never experimented with ci/cd but that was done to avoid overhead..<p>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.<p>I’d say keep the git-flow but structure things differently. git-flow has a lot of modern benefits!