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. 
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. 
You can download and install tentacles here.
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.
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.
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>
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 
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.
--projectspecifies the name of the Octopus Deploy project that we want to create a release for.
--versionspecifies the version number of the release in Octopus. We want this to contain the Jenkins build number.
--packageversiontells Octo.exe to ensure that the release references the right version of the NuGet packages that we published using OctoPack.
--releaseNoteswill appear in Octopus, and link back to the build in Jenkins. Of course, change the URL to the address of your Jenkins server
--deployTosetting specifies the environment in Octopus that we are deploying to.
--progressflag 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
--waitfordeploymentinstead. 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:
Deployment Step is as same as I described above.
Medinova Purge Step:
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
Onur Baskirt is a senior IT professional with 15+ years of experience. Now, he is working as a Senior Technical Consultant at Emirates Airlines in Dubai.