Search code examples
gitnugetworkflow

team workflow regarding simultaneously update same nuget in multiple branches

consider a team working with c# dotnet and Nuget packages between multiple projects and multiple branches, in 2 main enviorments TEST-ENV and MASTER(production ENV)

our current workflow regarding same Nuget update simultaneously in multiple branches

currently in the MASTER branch and in the TEST branch there is a Nuget package named X and its version is 1.0

developer A creates a Branch named BranchA based on MASTER Branch version 1.0 with Nuget X version 1.0, in this branch the developer updates Nuget X to version 1.1 and merged his development (development A) to the test ENV Branch.

developer B created a Branch named BranchB based on the master Branch (both branches are based on master 1.0). in this branch the developer also needs to update Nuget X, (to version 1.2), but if he does so he will overwrite development A thats in the Nugget package. Also he may not update locally the nugget to version 1.1 and then proceed to 1.2 because in BranchB there is not code to treat the new Nugget (development A).

so the current way we handle this is to tell developer B to wait for development A to arrive at the master branch, then merge master 1.1 to BranchB and only then update the Nugget and push development B to the test ENV.

The included image demonstrates our current workflow regarding same Nuget update simultaneously in multiple branches

this dynamics is really slowing down the teams efficiency, because in cases like these certain developers need to stop their work and wait for QA to approve a different developers work.

is there a way to optimize this workflow? but still keeping the fact that every development arrives to the master branch separately (to allow rollbacks to a specific development)

Solution

  • At any time, developer B can rebase branch B on top of a branchA or on top of Test Env 1.x in order to replay their development in a new context.

    That way, they can test locally if devB is compatible with devA or with what is being tested.
    And they can submit their work for testing since they are adding new commits on top of existing ones.

    This can be further automated/checked using, for instance, GitLab merge trains:

    Use merge trains to queue merge requests and verify their changes work together before they are merged to the target branch.

    But that depends on your Git repository hosting service.