Kentico + Octopus Deploy

Want to use Octopus Deploy to deploy your Kentico project to one or many release targets? Here are some tips to getting set up.

Picture of Michael Kinkaid

By Michael Kinkaid, CTO

October 17, 2014

Share

Want to use Octopus Deploy to deploy your Kentico project to one or many release targets? Here are some tips to getting setup.

Octopus What?

Octopus Deploy is a friendly deployment automation tool for .NET developers. Check it out here.  One benefit to using something like Octopus Deploy is that you can easily manage the deployment of a project to multiple release targets; e.g., development, QA, stage, UAT, etc.

Octopus Deploy

We use TeamCity as our build server.  Octopus has great support for TeamCity but also works with many other tools thanks to its API.  Check out the other integrations

Kentico CMS

Octopus Deploy works with NuGet packages.  The integration info on their website will guide you through the process of packaging up an ASP.Net project into a NuGet package.  Turning a Kentico project into a NuGet package that works takes a little added configuration.  This configuration is managed in a .nuspec file added to the CMSApp project.  This is an XML file that defines how the project should be packaged and sets meta properties.

The NuSpec File

Here is a .nuspec file configured for a Kentico project.  This has been added to CMSApp and named CMSApp.nuspec.

Code

Naming the Package

If we just package up CMSApp without the NuSpec file, then every package in Octopus will be called CMSApp.  If you work on multiple Kentico projects, then things are going to get a little bit confusing ("is this CMSApp package my project or yours?")  Use the <ID> node of the XML file to set the project name.  The name you put here will be the name of the package, which you can use when locating it in Octopus's package navigator:

Packages

Including Everything you Need

Kentico is made up of three projects: CMSApp, CMSApp_AppCode and CMS_MVC.  We'd rather not have three NuGet packages per project (multiplied by the number of release builds).  We can use just one (the main CMSApp) as long as we explicitly define what needs to be included in the package.

This is where the <files> node comes in.  We obviously want all the DLLs that have been built.  That will include the DLLs from the three Kentico projects.  CMSApp_AppCode, however, also has several services and handlers that are required (the files in CMSPages).  We are also adding Global.asax, which is also part of this project.

You can also use the <files> node to add in assets that may not be being built via MSBuild; e.g.,  JavaScript and CSS files that may be built by Grunt or Gulp tasks.

Finally we are including our web.config file and config transforms. We do this so that Octopus can transform the web.config file automatically based on the deployment target.

There's more than one fish octopus in the sea

So, what do other folks use to help automate the deployment of a Kentico build?  I really like the fact that, with Octopus, you can easily track which version is running on each deployment target.