3

Here's our problem - we have several solutions with multiple projects using our own nuget packages. We're following GitFlow, but not SemVer. Every time we're developing bigger feature or epic we want to keep it's code up to date with our development branch (which can have some other features or bugfixes done in time of developing aforementioned epic), so we want to merge it regularly. The problem is that in every merge, if there were any changes with our nuget packages, we have dozens of merge conflicts in all packages.config files in our projects. Doing it that way, merge takes too much time, especially since after merging we have to manually update nuget versions and install them in our projects. So every time we want to merge something we have to reproduce this steps:

  1. Merge branch
  2. Resolve all version conflicts
  3. Push updated nuget packages
  4. Install updated nuget packages

I've done some research, but I'm still not sure what's the best solution to simplify this process. Ok, we can use PackageReference or Paket with floating versions combined with GitVersion, which would automize steps 3 and 4 for our development branch, but problem with merging and conflicts remains, as our development branch uses release versions (X.X.X) and other branches are using prerelease versions (with -branchName tag). So with every update there still will be conflicts.

So my question is, how to best deal with that situation? Is there any way to solve this using nugets or maybe we can share our code in some other way? Shared Projects won't solve our problems, as our libraries are quite big and we don't want to include them in our solutions.

JayL
  • 33
  • 3
  • I must be missing somethign, you are merging your master branch (with hotfixes) back into dev? and you get a conflict because a nuget package has changed version on both the dev and master branch? – Ewan Jun 26 '18 at 10:40
  • are you checking in the binaries? – Ewan Jun 26 '18 at 10:42
  • Yes, that's the case. For example I made epic branch when master had package in version 1.0.0, I've already made some changes to this package on epic (1.0.1-epic) and also on master (1.0.1). When I want to merge master to epic, I'm getting merge conflicts in packages.config in alll projects using this package. – JayL Jun 26 '18 at 10:47
  • It seems like that should be a rare occurrence, you have hotfixed the same functionality that your are working on in the branch – Ewan Jun 26 '18 at 10:51
  • are you referencing packages which are compiled from the same git repository? – Ewan Jun 26 '18 at 10:52
  • Well, it's not just hotfixes. It's happening quite often that we want to update packages in different tasks, so every feature, bugfix or hotfix coming into master is causing this problems. Yes, we're checking in the binaries. No, it's different git repository. – JayL Jun 26 '18 at 10:56
  • what changes on master do you have that are not hotfixes? you said you use gitflow? – Ewan Jun 26 '18 at 11:22
  • dont check in the binaries, although that doesnt seem to be the issue – Ewan Jun 26 '18 at 11:23
  • I think it's naming issue, what I call master is not our release/production branch. I'll change it to development. But the rest is still accurate, for example we are using release packages on development branch (which is another issue). – JayL Jun 26 '18 at 11:27
  • tbh im still not really understanding. sure if you update the same package in two feature branches and then merge you will get conflicts. The question is why this happens all the time – Ewan Jun 26 '18 at 11:31
  • I would bet that problems are with code that we share, where we have e.g. some enums that changes too often. Refactoring is something we want to do in the future, but for now we're doing research if there's anything we can do to improve this process right now. If there's no way to avoid these conflicts maybe we should migrate from nugets to some other code sharing solution? – JayL Jun 26 '18 at 11:36
  • I have a feeling its probably more with your branch specific nugets. – Ewan Jun 26 '18 at 11:38
  • Nugets are branch specific only untill given feature is done. If we're doing some feature that requires changes in nugets, how else could it be done? We have to - for a time being - create branch specific version of this nuget package. – JayL Jun 26 '18 at 11:41

1 Answers1

2

OK Here's my guess.

You have a shared lib distributed by nuget and consumed by you application.

When you get a feature request for the application you create a new feature branch on its repo, but find that it will require changes to the shared lib

You create a feature branch on the library repo and publish a pre-release nuget

You consume the prerelease nuget on you application feature branch and continue testing the feature.

In another Application feature branch you have the same thing happening, when you finish that OtherFeature, you update the library and dev branch, but your OrigionalFeature is still on its prerelease nuget and you get conflicts.

The solution is to add and test features to the library independently of the application. Don't publish unfinished library features, finish them off and merge them in to master before publishing.

Once the library is updated with its new functionality, Then you can update the application to use the latest version and proceed to make a feature branch.

Obviously this means you need to work out your specifications bit more rigorously.

Alternatively you might try packing the library locally as the same version and use a directory as a file source, while you test so you don't have to update the version on the app

Ewan
  • 70,664
  • 5
  • 76
  • 161
  • First solution is I think what we'll be aiming for, but in the future - currently we're not able to fully test our libs independently of the application. There's a lot of legacy code not covered by any tests. That's why for now I'm leaning to second solution. We could separate development process from nuget and publish and install new packages only in build enviroment, which sounds like a good solution. Thank you, I think we'll give it a try. – JayL Jun 26 '18 at 13:25