NuGet has been around for some time, and still many companies are not using NuGet to help with dependency and packaging management. So why NuGet for your release management practices and what are the benefits of using the NuGet package manager tool?
The one thing that release management requires is a well defined and traceable package for release to a production system. The development and testing process goes through a few iterations before a final release package is created. Ideally, these packages or features should be in small units to be delivered continuously. The challenge for release management, is the packaging and tracking of dependences. This is where NuGet comes in.
In this blog, I am not going to be covering in any detail managing Online NuGet packages within a project. More information on the topic can be found at http://docs.nuget.org/docs/start-here/overview. I will however, be focusing on how NuGet packaging system solves a number of continuous integration and delivery issues.
Getting Started with NuGET
NuGet is an open source and is free to use. NuGet is a Visual Studio extension for development teams to manage and install third-party applications and libraries. NuGet includes a manifest to describe the package with the following elements.
The unique identifier for the package. This is the package name that is shown when packages are listed using the Package Manager Console. These are also used when installing a package using the Install-Package command within the Package Manager Console. Package IDs may not contain any spaces or characters that are invalid in an URL. In general, they follow the same rules as .NET namespaces do. So Foo.Bar is a valid ID, Foo! and Foo Bar are not.
The version of the package, in a format like 1.2.3.
The human-friendly title of the package displayed in the Manage NuGet Packages dialog. If none is specified, the ID is used instead.
A comma-separated list of authors of the package code.
A comma-separated list of the package creators. This is often the same list as in authors. This is ignored when uploading the package to the NuGet.org Gallery.
A long description of the package. This shows up in the right pane of the Add Package Dialog as well as in the Package Manager Console when listing packages using the Get-Package command.
(v1.5) A description of the changes made in each release of the package. This field only shows up when the _Updates_ tab is selected and the package is an update to a previously installed package. It is displayed where the Description would normally be displayed.
A short description of the package. If specified, this shows up in the middle pane of the Add Package Dialog. If not specified, a truncated version of the description is used instead.
The locale ID for the package, such as en-us.
A URL for the home page of the package.
A URL for the image to use as the icon for the package in the Manage NuGet Packages dialog box. This should be a 32×32-pixel .png file that has a transparent background.
A link to the license that the package is under.
(v1.5) Copyright details for the package.
A Boolean value that specifies whether the client needs to ensure that the package license (described by licenseUrl) is accepted before the package is installed.
The list of dependencies for the package. For more information, see later in this document.
(v1.5) Names of assemblies under lib that are added as project references. If unspecified, all references in lib are added as project references. When specifying a reference, only specify the name and not the path inside the package.
(v1.2) The list of .NET Framework assembly references that this package requires. These are references to assemblies that exist in the .NET Framework and thus should already be in the GAC for any machine. Specifying framework assembly references ensures these references are added when installing the package.
A space-delimited list of tags and keywords that describe the package. This information is used to help make sure users can find the package using searches in the Add Package Reference dialog box or filtering in the Package Manager Console window.
(v2.5 or above) Specifies the minimum version of the NuGet client that can install this package. This requirement is enforced by both the NuGet Visual Studio extension and nuget.exe program.
To get more information about NuGet you can review the NuGet documentation at http://docs.nuget.org/.
What in a package
For delivery to any system, some basic elements are required:
- Version of the code in the package
- Release notes for the software
- Reference or dependencies that the package requires
NuGet provides the metadata elements (as shown above) to describe the package requirements for delivery into a system. In the good old days, we would have to write-up release notes in the root folder of the package. These release notes did not provide a good description of the whole package as it flowed throw the delivery pipeline and only sometimes were the release notes used. Keeping the notes up-to-date was another pain for the release person.
NuGet provides a more mature way in handling release and version information. The metadata of the project is enclosed as a .nuspec file that lives within your project. As new development is added, the development team updates the files as needed. At compile time, the .nuspec file is accessed and adds the metadata to the .nupkg project. The .nupkg is just like a zip file that we would normally create with an additional build action to zip up the artifacts folder.
To view inside of a .nupkg, you can use the NuGet Package Explorer. The NuGet Package Explorer provides a view into the content and metadata elements. This is where teams can see the package information for release as it moves through the delivery pipeline.
Another feature that NuGet provides teams, build engineers, and release management is the ability to upload the package to a cloud or in-premises repository. With some small customization to your build template process, you can have an automated build, test, and upload process within your Team Build. The TFS NuGetter is one way to have an automated process to upload the package into a NuGet repository. The repository can have a number of different feeds to meet the workflow of the software development cycle.
For example, you can have a feed for the Project, Development, or QA, that match your build process.
Once the package has been uploaded to the feed, the team or an automated deployment process can connect to the feed and select the latest or previous version of that package to be deployed.
Deploy a NuGet Package
There are many different methods to release the package into a live environment. At this point, the package has everything it needs to deploy and has been tested. It is recommended that you have a production feed for your final release package. The good news is that you do not have to rebuild the code. That would not be a best practice and can cause bugs in the final software. If you don’t have an automated deployment process to run and deploy your code in ALL environments, then I would highly recommend that you implement one. A manual deployment process is too error prone and costly.
Here at Northwest Cadence we have been using Octopus Deploy for our deployment vehicle. This simple and very powerful light weight tool is wonderful for automating software delivery to ALL environments. It connects very easily to any NuGet repository feed to download the latest version of the package. The deploy promotion and dashboard solves another issues that build and release engineers face -transparency of what versions has been deployed to what environment.
The ability to promote a release quickly and reliably into the next environment with a few clicks gives this system the power to reduce some common problems of faster delivery cycles times and traceability for release management.
For continuous delivery, you must have a delivery pipeline and tools to support the practice. Here I have shown at a high level why NuGet is a wonderful tool for release management. The NuGet packaging system and metadata provides a framework to maintain the package information, requirement, and dependences easily. The NuGet repository and feed provides the definable sources to retrieve the package for deployment. We can move away from the file share that no one seem to remember the path name of and is difficult to find. We can now access the feed within Visual Studio or a URL. Overall, the deployment process is simply more streamlined. If you are moving to a DevOps, then NuGet will be at the heart of the solution.
NuGet is not just a dependency and application management solution. For build engineers, and release manager, NuGet is a solid packaging and delivery solution for your continuous delivery practices