Skip to end of metadata
Go to start of metadata

Before you can deploy an application using Octopus, you will need to bundle all of the executables, DLL's, configuration files, installation scripts, and anything else the application needs to run into a package. Octopus standardizes on the NuGet package format, a popular ZIP-based file format from Microsoft used in Visual Studio. There are a few reasons for this:

  1. NuGet packages have rich metadata, such as versioning, release notes, and author information
  2. Many tools exist to make creating and publishing NuGet packages easy
  3. NuGet packages can be consumed via a feed, so other applications can easily query the available packages
  4. Developer familiarity

NuGet

Icon

NuGet packages are basically ZIP files with extra metadata describing the contents of the package. They follow the Open Packaging Conventions, and use the .nupkg file extension. You can learn more about NuGet and NuGet Packages on the official NuGet website.

Creating packages

You can create packages in a number of ways:

Hosting packages

NuGet packages are kept in package repositories. A repository can be as simple as a file share, or it could be a dedicated server. For more information, see the section on choosing a package repository

What's in a package?

Octopus expects your NuGet package to contain all of the files needed to run the application when it is deployed (along with any scripts needed for deployment, and any configuration transformation files). 

An ASP.NET MVC application, for example, would look like this:

While a Windows Service application might look like this:

Note that in both examples:

  • Only binaries and files needed at runtime are included - C# source code files, for example, are not in the package
  • The binaries aren't just for the current application - they also include any other assemblies needed for the application to run

 

Tip: Structure the package as you want it extracted on disk

Icon

NuGet was designed for packaging libraries to be used in Visual Studio, which is a different usage scenario than that of deploying applications. When creating a library NuGet package, for example, NuGet encourages you to put binaries in a lib folder, and content files in the content folder. But for Octopus Deploy, this convention doesn't make sense - your ASP.NET application will expect binaries to be in a bin folder for example. Instead, just ignore the NuGet package structure conventions, and simply structure your package exactly like you want it to appear when extracted on disk.

Tip: No dependencies

Icon

NuGet packages can have dependencies - library A might depend on library B, for example. Again, this works fine for managing libraries in Visual Studio. But when deploying applications, your application will expect library A and library B to be in the same folder as the rest of the binaries needed to run the application. For this reason, Octopus ignores any NuGet package dependencies. Instead, simply ensure your package contains all of the binaries needed to run the application, as in the screenshots above.

 

 

  • No labels