
Ask HN: Git Branching for Continuous Delivery - pmhpereira
Hi HN,<p>At my company, we have small teams up to 4 people. Each team is responsible for its own product and libraries.<p>Libraries are shared using NuGet packages, created every merge and successful build.
These changes are propagated recursively to every project by an automatic commit.<p>Let&#x27;s assume we have 3 projects, A_Product, B_Library and C_SubLibrary:<p>- C is changed, revision number increases, new NuGet package is created, it triggers an update of B<p>- B has its NuGet packages updated, B is built, revision number bumped, new NuGet package for B, A is triggered<p>- A is updated, A is built, revision number++, installer is created<p>My biggest issue with this is how difficulty it is to maintain different versions of the product and libraries at the same time and the flood of automatic commits.<p>On my workflow, I have branches with CI&#x2F;CD per repository, one for each maintained version of product and libraries.
If I&#x27;m developing a feature, I create new branches without CI&#x2F;CD for the product and for each library that will change. I also update the Git submodules to the new branches.
I then change all NuGet references to Project references. Now I can start working on the needed changes of my code.
If I need something new on another team&#x27;s library, I have to wait for their NuGet package and manually update it on my projects.
When all changes are done I must merge them in order of dependency between libraries, so the packages are correctly propagated, or else something will break. I also cannot merge any of the Project references or manually-updated NuGet packages, as these will break the CI&#x2F;CD.<p>This is cumbersome and very time-consuming. I have done this multiple times and I still make mistakes and have to redo part of the process.<p>Each team has its own way of working with this CI&#x2F;CD setup, but none of them feels &quot;right&quot;.<p>TL;DR: Can you provide any insights on how to work with Continuous Delivery and some sort of Package Management involved?
======
karmakaze
Have you considered a monorepo? Normally only good for large, mature
(infrastructure-wise) companies but it couldn't be worse, could it?

~~~
pmhpereira
It certainly could be an option, but that would require a major change
company-wide.

This is more related to my personal distaste on how it affects my productivity
and my team's.

Other teams don't have a problem with it, although it is always a too
convoluted process to be able to push even the slightest feature or bug-fix.

