1

I have a monorepo, that has say 5 .net core APIs, and the all use several common libraries:

/api1
/api2
...
/api5
/common1
/common2

I am using a single master branch strategy and want my master branch in sync with what is deployed to my production environment.

These are all using .net Core 2.2; I want to upgrade them all to .net core 3. However I need to get "api1" out to production quickly, and don't have time to upgrade all the APIs, I just want to update api1 and the common libs. However if I do this, all my other APIs will be in a broken state in the master branch.

I was thinking I could create a release branch of the state now, and create another release branch for the upgraded API and common libs? However that means the master branch becomes kind of a dev branch, not representative of what is deployed in production? How do I solve this?

Also, how do you make single API Git branches for releases rather than a release branch for the whole monorepo? (/releases/ap1/1.1) Do you just ignore everything but the API the release is for?

halfer
  • 19,824
  • 17
  • 99
  • 186
user210757
  • 6,996
  • 17
  • 66
  • 115
  • Are you able to have the different APIs on different versions of .net Core within the same repo, or is it arranged such that they have to be on the same version? – halfer Apr 04 '20 at 10:11
  • I assume that api1 has been upgraded to .net Core 3, and that you want to deploy that on its own, while keeping the other APIs on 2.2. – halfer Apr 04 '20 at 10:13
  • @halfer I'd like them to be on different versions, but they share a common lib. I supposed I could compile and reference a DLL, but don't know if that means I lose some monorepo advantages? – user210757 Apr 08 '20 at 15:38
  • Ah, and the library is in your repo, or pulled in as dependency? OK, could you have a mono-repo for each major lib version? – halfer Apr 08 '20 at 16:05

1 Answers1

1

These are all using .net Core 2.2; I want to upgrade them all to .net core 3. However I need to get "api1" out to production ASAP, and don't have time to upgrade all the APIS, I just want to update api1 and the common libs.
However if I do this, all my other apis will be in a broken state in the master branch.

That cannot be avoided, if you want master to represents what is deployed in production.

The development of the other (now broken in master) api will have to take place in a dev branch, before being merged back to master when they are ready to be released.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • I'm trying to follow this branching strategy https://learn.microsoft.com/en-us/azure/devops/repos/git/git-branching-guidance?view=azure-devops – user210757 Apr 03 '20 at 13:35
  • @user210757 I don't think this is incompatible with what you want to do: you just need to consider dev as your new master (from which feature branches are managed), while your actual master still represents what is in production (including api1 updated). – VonC Apr 03 '20 at 13:44