1

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)

pocketGod123
  • 27
  • 4

1 Answers1

1

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.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Basically I would rather avoid merging several developments at the TEST ENV level because: we have a stage environment that we swap with the production, so I would like to maintain the abillity to rollback specific developments from the stage. since we are using git with azure devops and not tfs we do not have specific changesets to rollback, only full repositories to compare to each other. regarding the merge trains, I'm afraid that from my very short research they are not compatible with our azure devops environment that includes our repos and pipelines. – pocketGod123 Feb 07 '23 at 08:29
  • @pocketGod123 OK. I did not see the word "Azure" anywhere in your question. Note that you are not supposed to merge integration branches between themselves. Only feature branches (that way, it is easier to not include one of those in an integration branch like prod, because it was deemed not ready in staging). See [gitworkflow (one word)](https://stackoverflow.com/a/216228/6309). – VonC Feb 07 '23 at 08:31