Ask HN: Git Branching for Continuous Delivery
At my company, we have small teams up to 4 people. Each team is responsible for its own product and libraries.
Libraries are shared using NuGet packages, created every merge and successful build. These changes are propagated recursively to every project by an automatic commit.
Let's assume we have 3 projects, A_Product, B_Library and C_SubLibrary:
- C is changed, revision number increases, new NuGet package is created, it triggers an update of B
- B has its NuGet packages updated, B is built, revision number bumped, new NuGet package for B, A is triggered
- A is updated, A is built, revision number++, installer is created
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.
On my workflow, I have branches with CI/CD per repository, one for each maintained version of product and libraries. If I'm developing a feature, I create new branches without CI/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'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/CD.
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.
Each team has its own way of working with this CI/CD setup, but none of them feels "right".
TL;DR: Can you provide any insights on how to work with Continuous Delivery and some sort of Package Management involved?