Releasing new software has to be simple and super fast! That was not the case for our company-internal class libraries till a couple of month ago until I finally decided to take the time to optimize that release process.At the company where I'm working at currently, we have an internal class library which bundles a series of utilities with the scope of helping devs doing their day-to-day job. So far so good, however, there has always been a thing that puzzled me right from the beginning was the cumbersome release process of that library. Creating a release bundle consisted in
- incrementing the version number in the AssemblyInfo
- building the library project in release mode
- opening the bin folder
- zipping the dlls
- uploading the zip to our company-internal wiki page with a version history of the release
That's really tedious, isn't it? It sometimes took longer to create a new release than to fix a bug. So a couple of months ago I decided to optimize that: using NuGet. If you're a .Net dev you for sure already heard about it.
NuGet is a Visual Studio extension that makes it easy to install and update third-party libraries and tools in Visual Studio. When you use NuGet to install a package, it copies the library files to your solution and automatically updates your project (add references, change config files, etc.). If you remove a package, NuGet reverses whatever changes it made so that no clutter is left.The idea was to create a local, company-internal NuGet repository.
Setting up a company-internal NuGet RepositoryThat turned out to be simpler than expected. Creating a local NuGet repository is as simple as creating a folder on some network share and to deploy all of your NuGet packages there.
Configuring Visual StudioIn order for NuGet to also search on your private repo you need to add the URL to the repository in your NuGet Package Manager Settings under
Tools > Library Package Manager > Package Manager Settings.
When you now invoke the Nuget Package Manager on a Visual Studio Project or Solution you should also see your private repo listed as a possible source:
You're ready! You can now start packaging your class libraries and dlls as NuGet packages.
Automate to the death?I'm not going to write on how to create NuGet packages as NuGet has excellent docs on this. What I did is to create a
.nuspecfile for the class library and then a nice
publishRelease.batcontaining something like
msbuild Siag.Base.csproj /target:Rebuild /property:Configuration=Release nuget pack Siag.Base.csproj -Symbols -Prop Configuration=Release move *.nupkg \\snip\snip\NuGetRepository
Releasing today means...
- Incrementing the version number in the AssemblyInfo.cs
- double-clicking on the publishRelease.bat
Like it! :)