Automated Deployment with Octopus Deploy

In this article I will explain how to do automated deployments with Jenkins and Octopus Deploy.

Install Octopus Deploy

First you should have a Windows Server and MSSQL/SQL Express database for Octopus deploy. All requirements and installation process is described here. Please, follow those instructions. Also, you can see Octopus Delivery Process in below figure.

  • Developers commit their code into your existing source control system
    You might be using Git, Team Foundation Server, Subversion or Mercurial; the choice is up to you.
  • Your CI/build server compiles the code and runs unit tests
    Again, you might be using TeamCity, Jenkins, Bamboo, Team Foundation Server or CruiseControl.NET; the choice is up to you.
  • Your application is packaged into a NuGet package
    When the build is done, your CI/build server bundles all of the files – the binaries, images, scripts, configuration files and so on – needed to deploy your application into a NuGet package. [1]

Install Tentacles

Tentacle is a secure, lightweight agent service that Octopus uses to deploy software. Tentacle runs as a Windows Service, and is installed on all of the machines that you plan to deploy software to, such as your application and web servers.  In essence, Tentacle is a job runner. It waits for Octopus to give it a job (deploy a package, run a script), and it executes it, reporting the progress and result back to the Octopus server. [1]

You can download and install tentacles here.

Create Environments

Click environments tab and create environments as DEV, TEST, STAGE, and PROD. It depends on your architecture.

You should also configure required fields in environment edit page and save the correct tentacle ID. We should also set a role that deployment target provides.

Go to the server where tentacle manager installed. This is the server that we will going to deploy the packages.

Then, we will paste that tentacle ID in test target machine.

Add Project

Set your project’s Package ID

Do your IIS settings. #SiteName is a variable and it is changing with respect to your environment such as test-yourcompany.net or stage-yourcompany.net etc.

If need you can create a new project lifecycle for your project and you can set project retention policy to keep only given number of latest releases in your octopus server. In order to do this, you need to go Library –> LifeCycles

Then, we can change our Lifecycle from Project –> Channels

Set your web.config values and variables for each environment.

and you can add another settings based on your project and its requirements.

Jenkins Part

First, you should add octopack and nuspec file to you project. Here you can find instructions.

In my C# and Jenkins integration article, I described how to build, run unit tests in Jenkins. In that Jenkins job we need to do some modifications. I will list them below.

First, it is better the keep latest 3 or more builds in your build machine. It will prevent to blow-up the disk size.

Then, we need to do source code management settings.

In order to mask your octopus api key, you can add OctopusApiKey variable via from “Mask Passwords Plugin” as shown below.

Build (Nuget Restore)

In order to get and load nuget packages, I used nuget restore command as shown below. I hold all my nuget configuration in nuget.config file.

Below is my nuget.config file:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <add key="NuGet official package source" value="https://nuget.org/api/v2/" />
    <add key="LocalNuGetFeed" value="YOUR LOCAL NUGET SERVER IF EXISTS. IF YOU DONT HAVE REMOVE THIS LINE" />
  </packageSources>
  <disabledPackageSources>
  </disabledPackageSources>
  <activePackageSource>
    <add key="All" value="(Aggregate source)"  />
  </activePackageSource>
</configuration>

MSBuild

I changed my MSBuild script as shown below. This is the reference page that I used to do configurations –> https://octopus.com/docs/api-and-integration/jenkins [2]

The settings are:

  • RunOctoPack: specifies that OctoPack should create packages during the build
  • OctoPackPackageVersion: version number that should be given to packages created by OctoPack. Since Jenkins build numbers are integers like “12”, we combine it with “1.1.” to produce package versions such as “1.0.12”.
  • OctoPackPublishPackageToHttp: tells OctoPack to push the package to the Octopus Deploy server. Read more about the built-in NuGet repository in Octopus. You’ll find the URL to your repository on the Library > Packages tab in Octopus
  • OctoPackPublishApiKey: your Octopus Deploy API key

I skipped Unit Test run, report executable batches. You can find them in this article.

Deployment Script

  • The --project specifies the name of the Octopus Deploy project that we want to create a release for.
  • The --version specifies the version number of the release in Octopus. We want this to contain the Jenkins build number.
  • The --packageversion tells Octo.exe to ensure that the release references the right version of the NuGet packages that we published using OctoPack.
  • The --releaseNotes will appear in Octopus, and link back to the build in Jenkins. Of course, change the URL to the address of your Jenkins server
  • The --deployTo setting specifies the environment in Octopus that we are deploying to.
  • The --progress flag tells Octo.exe to write the deployment log from Octopus to the log in Jenkins. This flag was added in 2.5; in previous versions of Octo.exe you can use --waitfordeployment instead. You can also remove this flag if you want the Jenkins job to complete immediately without waiting for the deployment in Octopus to complete.

When all settings are done and run your Jenkins job, you will see that Octopus will deploy created package to the Test Environment.

Live Deployment Strategies

If you want to do live deployment, you need to change your Octopus process. It depends on your environment, projects, infrastructure, etc. I want to give you an example for live deployment. Assume that, we are using F5 as load balancer, we have 2 live servers and also we are using Medianova as CDN.

For above specifications, our process should look like this.

First, we need to disable a node from load-balancer, then wait 3 minutes, then deploy a new package to the server and connect it to the load balancer and refresh the CDN if you have. Also you can add DB step here if you have any DB deployment exists.

Load Balancer Step:

Wait Step:

Deployment Step is as same as I described above.

Medinova Purge Step:

HTML and JavaScript Deployments

You can zip your html and javascript files to deploy your environments. To do this you should use below build scripts.

Create a .zip package:

"C:\Tools\Octo\Octo.exe" pack --format=zip -id=dejavu-web 
--basePath="C:\proj\dejavu\test\ats-webapp\app" 
--version 1.1.%BUILD_NUMBER%-WEBDEJTEST 
--packageversion 1.1.%BUILD_NUMBER%-WEBDEJTEST 
--server OCTOPUS_SERVER_IP:9010 
--apiKey %OctopusApiKey%

Push the package to the Octopus Server:

"C:\Tools\Octo\Octo.exe" push 
--package dejavu-web.1.1.%BUILD_NUMBER%-WEBDEJTEST.zip 
--server http://OCTOPUS_SERVER_IP:9010 
--apiKey %OctopusApiKey%

Create a Release:

"C:\Tools\Octo\Octo.exe" create-release 
--project dejavu-web 
--version 1.1.%BUILD_NUMBER%-WEBDEJTEST 
--packageversion 1.1.%BUILD_NUMBER%-WEBDEJTEST 
--server OCTOPUS_SERVER:9010 
--apiKey %OctopusApiKey% --deployto=TEST --progress

Thanks.

-Onur

7 thoughts on “Automated Deployment with Octopus Deploy”

  1. This article looks like the author wrote this for his future reference. Here it is assumed that the reader know the concepts of Octopus – ‘Lifecycle’, ‘Channel’ etc.
    Came here to understand the above opus concepts but no explanation.

    Reply

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.