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?
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!