Menu
Our team has experimented with git submodules for some core CRUD functionality shared by most of our products. We have also successfully used Nuget packages (self-hosted now) for some common utilities.
Our core functionality changes often enough that keeping submodules properly committed is proving to be more of a chore that we expected. I am considering moving the core functionality from a submodule to a Nuget package but am wondering if the frequent updates to the packages would be even more of a pain in Nuget.
Does anyone have any experience and guidance as to what other challenges I might encounter before making this slightly intrusive change to our architecture and process?
488
In most cases, Git submodules are used when your project becomes more complex, and while your project depends on the main Git repository, you might want to keep their change history separate. Using the above as an example, the Room repository depends on the House repository, but they operate separately.
The first important advantage to using submodules is that submodules allow you to keep the commit history of the component you're including in your project. Assuming the component you're adding is publicly available as a git repository, incorporating this component without the use of submodules presents a problem.
If you pass --recurse-submodules to the git clone command, it will automatically initialize and update each submodule in the repository, including nested submodules if any of the submodules in the repository have submodules themselves.
As with anything, it depends. Have you considered using a separate CI package repository where every commit to the core module produces a CI package?
The biggest challenge imo is package versioning, as NuGet doesn't support SemVer yet to its full extent (e.g. pre-release versions + build number).
EDIT: nuget.org now supports SemVer 2.0 package versions. See this spec: https://github.com/NuGet/Home/wiki/SemVer2-support-for-nuget.org-%28server-side%29
Use SemVer properly. You usually don't know the released version number upfront, so your CI package version continues from the latest stable release. CI packages as such are to be considered pre-releases.
E.g.: 2.2.0-CI201209140650 (which is a CI build taken on 2012-09-14 at 06:50 for an upcoming 2.2.0 release) <-- note: this release version can still change, but there's always going to be an update path.
If you adopt SemVer v2.0.0, you can even adopt the following example: 2.2.0-CI.2012.09.14.06.50.
Important note: nuget.org (and by extent any other NuGet server/service out there such as MyGet or VSTS) does not support multiple package versions differing only by build metadata!
This has worked for me using these constraints (and some proper TeamCity build configurations). So in short, these are the hassles:
Hope this helps!
119
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
