Octopus Deploy and NuGet

At this point, we’ve taken a high-level perspective as to the technologies that Octopus Deploy utilizes. One of the pillars of Octopus Deploy is NuGet. In my opinion, without NuGet, Octopus Deploy could not exist.
What is NuGet? In a nutshell NuGet is an open source package management system for .NET. It allows for the downloading and installation of any files into a .NET solution or project. For most, if not all Windows developers, NuGet is practically ingrained in development.
Here’s a screenshot of the NuGet Package Manager that allows you to download, update remove NuGet packages from your solution and projects.

Still prefer a command line? No problem.

NuGet has arguably made the biggest impact in developing .NET apps compared to all other technologies in the past two to three years. You want an open source library that solves your specific problem? There’s probably a NuGet package available. You want to use the latest version of such-and-such framework? You want to update all your external libraries in a single command? You want to remove one or all packages? No big deal. No need to deal with config files or manually moving files around in your solution or managing the intricacies of configuration. Just type a command (or click a button) and go.
Within Octopus Deploy, only the projects within the solution need to be packaged up into a NuGet package. NuGet is the container for which your applications will move from server/environment either from the NuGet server itself or through Octopus Deploy. You can control the upload options within your deploy process as to how packages should be delivered.
It seems so simple now and yet so strange why no one had thought of using NuGet in this fashion. I’m not aware of any other release management system that uses NuGet packages outside of Octopus Deploy. (Note: Red Gate’s Deployment Manager is running an Octopus 1.0 license under the hood –  but the two products are separate and incompatible with one another).
Octopus Deploy provides the OctoPack, an automated NuGet packaging solution for your CI build server. I’ve currently been using the OctoPack for TFS solutions and it’s a breeze. You can simply install the OctoPack via NuGet (yay for consistency). That said, you’re not obligated to using the OctoPack, although it is a lot easier using it.

Why NuGet packages? Why go through the hassle of bundling your projects into NuGet packages? Most NuGet packages are for pieces of an application. Usually a dll or perhaps a framework and some config files, etc. but not a whole application. What’s the benefit?

• Automated versioning
• Rollbacks*
• Central repository
• Metadata
• Consistency

Automated versioning
Whether you use the OctoPack, PowerShell scripts or another solution for building your NuGet packages, the process can be automated. That said, the task of packaging itself is trivial but the bigger point is that with automation comes versioning. Being able to version your applications in one NuGet package is a huge benefit. Just as pieces/parts of applications are versioned, your applications themselves should be versioned as well as a whole and NuGet simply forces the practice. How you decide to version your builds is up to you. For deploying applications into any environment, having a version number helps logically keep track of changes.
I can recall countless projects at different organizations where there was no versioning whatsoever. Whatever was in the TFS build drop folder, teams would xcopy to another file share and that was that. Of course if something went wrong or the wrong changeset was deployed, the fix was to get the specific changeset in Visual Studio, rebuild and xcopy all over again. Not exactly elegant, foolproof or audit-able isn’t it? Well, NuGet packages lead to versioning which leads to our next point: rollbacks.
Rollbacks*
For .NET applications, rolling back is a matter of redeploying the NuGet package version you want. Within Octopus Deploy it’s easy to create a manual release and rollback to a previous version; For Web sites, Windows Services, MSI installers, etc. rollback functionality is not a problem. You can see below when searching for a specific package to deploy, you have the option of searching for any package within the feed.

The caveat of rollbacks is naturally of course, SQL databases. Hence the asterisk (*) on this section. Schema changes are probably the most cumbersome followed by data, but what it comes down to is what SQL scripts need to run AFTER you’ve deployed your changes.
So can you do SQL database rollbacks? Sure. As long as you have the necessary SQL scripts to undo the changes that were made, then yes. But most, if not all organizations I would imagine do not plan or script for those types of scenarios unless absolutely necessary.
Central Repository
A NuGet server is simply a server that stores NuGet packages and provides feeds to download from. There are several options in NuGet servers available today for free, or commericial options such as ProGet, or online services such as myget.org.
You can have Octopus configured as a NuGet repository to store your packages, however there’s no difference in using an external repository whether it be on-premise or in the cloud. In my experience, I’ve kept the repository on-premise but off of the Octopus Server itself. I’ve also used myget.org with no problems whatsoever. Octopus and NuGet servers are simply a seamless mechanism.

Metadata
While metadata could be considered a superset of my previous point on versioning, I felt that versioning deserved it’s own highlight. You can version with little to no additional information so metadata gets it’s own bullet point. Within your project, there’s a nuspec file that allows you to describe your application or component in detail and allows the Octopack (or NuGet.exe) to create a NuGet package. This metadata simply cannot exist just copying files from one folder to a file share. This also makes managing different versions of your application manageable within your own NuGet server. Being able to leave release notes or comments within your NuGet package is a nice documentation feature that requires little to no effort on your part.
You can see from the image below the metadata that’s available for each NuGet package. Here’s a NuGet Package Explorer view of the Entity Framework 6.1 directly from NuGet.org.

Consistency
NuGet packages can be copied from one NuGet server to another. There’s no real distinction or differences within packages themselves. Having all your eggs packages in one basket is also advantageous in deployments as it guarantees the same bits across environments. No need to recompile projects or rummage around TFS drop folders (or with whatever CI solution you use). Having a centralized repository allows you to have any of your previous builds ready at a moment’s notice.
One Additional Benefit (TFS only)..
With the previous point on consistency, for those who use TFS and are looking into Octopus Deploy, having NuGet gives you an additional benefit: less need for storage space for your build server(s). In TFS, using and pushing NuGet packages to a NuGet server allows you to keep a more strict limit on your retention policies so that you don’t need to keep the last 5 or 10 builds on the TFS build server. For build servers with lots of TFS projects, storage space is always a premium as TFS builds are notoriously large in size. However if you move to NuGet and upload the resulting packages to a NuGet server, there’s no need to retain the contents in the drop folder. You can update your TFS build definitions to keep one or two previous builds and relax now that your build servers should not run out of storage space.
Putting it all together
The beauty of Octopus Deploy is that as long as your projects are in a NuGet packages and in a feed, Octopus can deploy your projects to any tentacle attached to the server. For me, Octopus really forced the issue of NuGet packages and after working with it, I’m glad I drank the proverbial kool-aid.
If you’re developing .NET apps, NuGet is a necessity. As an application developer, I feel like I have been missing out on the fun and flexibility of NuGet packages that my projects should have been doing from the start. Going forward, NuGet will simply be incorporated as part of my development practices.
Knowing that at any moment I can deploy to any number of machines within my Octopus environment, is a such a relief. I know the bits will be the same across all servers and Octopus will make whatever configuration changes I configure. I get all the benefits of metadata which and with versioning, I can rollback if need be simply by having a central repository. I have yet to do a rollback, but knowing that I have the previous builds on the NuGet server, I fear nothing and neither should you. If you’re not using Octopus Deploy today, check it out at http://octopusdeploy.com/downloads.
And with that, we’ll wrap up this high-level topic of Octopus Deploy and NuGet. This week is fairly busy as I’ll be presenting Octopus Deploy for the Chicago ALM Users Group tomorrow night.