-1

Essentially our team is dealing with a challenge where every release we are cherry picking fixes to go to the next release environment, and I would love help.

Let’s say we have 4 tickets A, B, C, D

And we have 3 environments:

Dev, QA, master (release branch)

Right now we deal with the challenge of:

All tickets are done dev work and they move to QA,

In QA ticket A, C, D pass but B is reopened (because some portion of it didn’t work) and it is now time for a release, so we must cherry pick fixes A, C, D to push to master. But turns out fix D was reliant on fix B. So we go back and add the dependency B had for D.

This is simple enough with 4 tickets but we have dozens and are stuck cherry picking and smoke testing all day, and naturally we miss a fix, and have to go back to do some more cherry picking to make sure the dependencies are also in.

has anyone dealt with this problem or have a solution?

  • 1
    This is basically the same broken workflow as this recent question: [Branching and release strategy - A best option to bring changes between develop to release branch](https://stackoverflow.com/questions/71784213/branching-and-release-strategy-a-best-option-to-bring-changes-between-develop) In short: **stop merging things that haven't been tested yet**. – IMSoP Apr 13 '22 at 15:02

1 Answers1

1

I assume this is the actual problem:

But turns out fix D was reliant on fix B.

Ask yourself the question: How could the developer of D have possibly seen the changes introduced by B?

I would try to impose a branching system, where each developer is only allowed to use whatever has already passed QA, not the work of other developers, not even his own.

SebDieBln
  • 3,303
  • 1
  • 7
  • 21