How to prepare an Octopus environment to deploy Web Sites following a Pipeline CI/CD

With this blog article we will explain, using examples, how to prepare an Octopus environment to deploy Web Sites following a Pipeline CI/CD. We will start from an already prepared Octopus server and try to configure the environments, the instances where we will deploy, the deployment process, versioning, and the step between environments.


Adding Environments and Instance Configuration

The first step is to add environments to identify the machines and our development. To do this, we have to go where the image is pointed out and click on “ADD ENVIRONMENT”, where a pop-up menu will appear to introduce the name of the environment. We have chosen to create the environments DEV, TEST, PRE and PRO.


Added several Instances to the Deployment Targets list

For this blog we have prepared two Instances, one DEV and one TEST, both configured with the IIS and ready to move Web Sites away. Both Instances will have a tentacle, which is a software that connects Octopus with the Instance to perform the displays and configurations of the project. The easiest way to do it is to follow the next images:

We select the OS (Windows in our case) and give Listening Tentacle.

A new window will give us a link to download the Tentacle (1) and gives us the Thumbprint (2). We must pass the Tentacle installer to the Instances and introduce the Thumbprint in the Instances, selecting the same option of addition (Listening Tentacle in this case). Once installed, we must introduce the IP of the Instance in (3) and hit Next to leave it configured.

Afterwards, we will fill in your details by putting your name (1), environment (2) and role (3) (which is an identifier for the machines). Then we give him to Save and we would have our Instance saved and ready:


Package in the Octopus library

The packages in Octopus will contain the application that we want to deploy on the Instances. These can be identified in two parts:

– Package ID: which is composed of the name of the Package.

– Version number: that is the version of the Package.

It is recommended to have a nomenclature to be able to differentiate the versions. We will use the following one:


The environment would be DEV, TEST, PRE and PRO. The NumEnvironment would be, in this case, 1 for DEV, 2 for TEST, 3 for PRE and 4 for PRO. The versions would identify the version of the Package for that type of environment.

We are going to deploy a Package with the project “Hello World by Enimbos” in the DEV environment, which will contain a simple web. Its name would be:


It should be noted that the packages supported by Octopus are in NuGet, zip, tar, jar, war, rar, … format, among others. We will use ZIP.

To upload the Package, we have to go to Library -> Package -> Upload Package, as you can see:

A window will pop up to select our ZIP and upload it.

Once the package is uploaded, they will show us the details. See:


Creating and Configuring an Octopus Project

Once the Package is uploaded, we can proceed to create an Octopus Project. We won’t go too deep into this point, but we will briefly explain the process.

To create the project, we have to go to Projects and click on ADD PROJECT:

NOTE: See that you can create groups to group Projects.

A pop-up menu will appear to enter the name, description, Project group and Lifecycle (environment application step). Fill in and hit Save:


Once created, it will redirect us to our project and we will be able to define its processes.

To define our process we will have to go to Process and then add as many Steps as necessary. You can see below the order and also a list of Steps that we have defined:

An Octopus project is composed of Processes that are executed in order. Octopus is able to offer a huge variety of Steps that we can use to prepare our instance with great ease.

The first step is to define an App Pool that will host the Web Site we are going to deploy. The second step is to deploy the Web Site in the Instance.

It is important that each step of the Process can be assigned Environment tags (DEV, TEST, …) and Role tags (enimbostest), being this last one the one that indicates in which Instances this operation will be performed.


Creating Releases to Deploy

To do this, we will create a release by hitting the Create Release button and giving it an identifier:

A relay is a launch. Each relay consists of everything that is the project at the time of its creation: process, variables, etc. Also the packages

As you can see in the image, it is recommended that the release version follows the same style as in Packages, but with one more:


The Num field would indicate the number of the deployment for that version. For example, since we want to deploy this Package for the first time, its version would be:

If we create a new relay of this version, it would be:

This way, we will be able to control our project easily.



Once the release is created, it will redirect us directly to it. We can also go to the Release by clicking on Releases, which will show us all the releases already created.

To display a release, we simply have to hit either of the two buttons on the right of Deploy. See:

Each release can be deployed infinitely. All releases are available even if there are subsequent versions, unless they are deleted.

Once you click on one of the Deploys, you can select the environment (1) and exclude steps (2) in this display, among other options. In this case, we will simply display over the DES environment:

Once we give Deploy (3), it will start the deployment and inform us of its progress, as we can see below:

If we go to the server, we can see that it has been deployed. See:


New versions Deployments

Since the web seems to us to be a small thing, we are going to make a new deployment on DEV. To do this, we will upload the new version by calling it as follows:


So it will be grouped under the name of Package HelloWorldByEnimbos_DEV, where we can see the versions of the Package.

If we want to deploy the new Package, we’ll have to create a new Release where we’ll select the version we want to use:

We will deploy and, once we have finished, we will be able to see the new results on our Web Site:

It’s much better now!!


Deployments in other environments

Let’s imagine that this last Package, HelloWorldByEnimbos_DEV.1.1.2, we want it to go out to the TEST environment. To do this, we will upload the Package with the name:


We modified the Process to display this in TEST:

We created a new Release and we will see that it will be deployed in the TEST Instance that we had assigned.

Once deployed, we would have it ready in the TEST environment.



This example has been a good vision of a Pipeline CD/CI. We have started from the development environment, deploying new versions in it and we have passed it, finally to the TEST environment.

Octopus is characterized by its flexibility. For example: we can do the same with the same initial version instead of creating a new explicit package for TEST. We can also create another project for another environment, add a new role to a machine, deploy a step or a process in more than one role and/or environment… Moreover, its huge variety of processes allows us to carry out any action easily.

Octopus has been one of our pillars when offering support to our clients in the development and implementation of their applications using the base of a Pipeline CD/CI.

Related Posts