Packages

In the previous activity, we discovered the architecture for Octopus and how to install and configure Octopus. But, Octopus can’t just deploy an application.

It requires a packaged application, in a supported format, to do this. Let’s explore this further in this step.

Packages

A package is a bundle of everything that is needed to run an application, such as executable(s), configuration files, DLLs, installation scripts, images and other assets.

A package is typically versioned. Some package formats rely on embedded metadata for versioning, while others have to rely on conventions.

Octopus does not dictate from where it gets the packages and it supports multiple sources of packages and package formats:

• NuGet
• ZIP
• Tar (uncompressed or compressed with gzip or bzip2).
• Docker image

Octopus has two requirements for a package: an IDand a version.

Versions need to follow the semantic versioning (Semver) scheme.

Some formats such as NugGet support metadata. Here, it is enough to add more properties to add an ID and a version. With other formats (ZIP or Tar, for example)the ID and version are defined in the filename by convention. The convention format is <package id>.<version>.<extension>.

That is: MyCompany.Web.Shopping.1.4.1.zip

The location where packages are stored is called the package repository. Octopus has an internal package repository, but if you want, it can use external repositories from third parties.

Learn more about:

• Supported package formats by Octopus.

• Versioning.

In the following step, we will look at packaging applications.