GoCD: Versioning .Net Assemblies
I recently updated my versioning on my build server to help separate CI builds from builds that are being publicly distributed. My versioning scheme for CI builds looks like 5.4.4-239CI37380 following SemVer 2.0 this gives me Major.Minor.Patch-PreRelease. My PreRelease is the “Go Counter” + “CI” + “Source Revision Number”.
Unfortunately, assembly versions use a different scheme, Major.Minor.Build.Revision and are only allowed to have numbers and no dashes (AssemblyVersionAttribute). So, I ended up keeping the CI version for file names, but changed the assembly to just use the Major.Minor.Patch for the assembly Major.Minor.Build (you with me?). Then for to help identify different assemblies I added the Go Counter to the end.
The lesson is to only use numbers in your .Net assembly version numbers.
Deploying NuGet Packages Instead of Zips
I was on a project to improve an application deployment process that used zip files for packaging the applications. Zips are good. They allow you to package and compress files into one bit sized file, but there is so much more to be had with a dedicated package solution. Maven, gem, wheel, npm, cpan, rpm, deb, nuget, chocolatey, yum… the list goes on and with so many options to provide an improved package for deployment its hard to justify using plain old zips.
Since this was a .Net project I focused on NuGet. NuGet is itself a zip file, but a zip on steroids. Zip provides the compression and NuGet adds additional meta data and functionality.
- Standard package meta data and file layout.
- Versioning ala SemVer.org.
- Package manager to control install, upgrade, and uninstall.
- Dependency management.
- Having a package manage file deployment means you have a repeatable process as opposed to manual where one missed file can kill you. Also, when I deploy the same package multiple times the system is in the same state after each deployment, idempotent.
Enough of the sales pitch. Actually, one problem that I had with using NuGet alone was no easy way to validate the package through checksum. So, in addition to NuGet, using a dedicated artifact repository solution like Artifactory gives an added layer of comfort. A good paper, although biased, on Artifactory can be found here.
Phil Haack did a post about SemVer 2.0, a formal specification for public API versioning. I think it’s a novel idea as it puts a name and formal structure to what a lot of dev shops I know have been doing. It also allows packaging tools to standardize, like the work Phil talks about with NuGet.
I have added “integrating SemVer and NuGet into CI” to my very long list of things to do for my main side project. That list just keeps on growing.