Adding continuous deployment into your workflow is an essential step for any professional organization. Depending on the level of the technical ability of a client, the first process improvement I've seen to introduce for clients is the ability to automate their deployment process. Having an automated build and deployment process is vital to ensure your deployments don't take the website down.

If you're reading this and you're on the fence about 'wasting' time implementing continuous integration and deployment... then PLEASE trust me, you'll be saving your company months' worth of man power, even if the task seems a little daunting at first. Speaking from personal experience, if you can be the person who introduces an automated deployment process, your company/client will appreciate it.

No matter how many features you build, if you can introduce a system where you can rollback bad deployments with a click of a button and remove the risk of a company's website from going down out-of-hours, which in some extreme cases I've seen, has cost companies thousands in lost reveneue, then something that you might consider as not part of your job, can actually become a major feather in your cap.

As well as earning you some brownie points with your boss, spending a little upfront time making sure everything is automated will make your life a lot easier and enjoyable. It's not uncommon to come into a client's office and find out the deployment process is copying a handful of DLL's onto servers. In 100% of the cases, this process causes far more problems than the relatively easy process of setting up continuous integration.

It still amazes me that many enterprise-level sized organizations don't do this, but hey ho... it is what it is. My assumption in this article is that you're setting up continuous deployment for the first time and you have decided to use Octopus as your deployment tool. Octopus has been around for several years now, it's well established and every developer I've ever had a conversation with about it has been positive, so it's a good choice. Your next step then is to decide how to set-up Octopus.

I think the main goal for continuous integration and deployment, is usually to just get something working, however, from experience ranging from writing MSBuild scripts, batch files, PowerShell script, setting up steps in Octopus and even having to update a custom deployment tool in a previous company, some ways will definitely save you hours' worth of your life compared to others. My hope of this article is to highlight where the pain points kick in so you can hopefully be aware of them before you finalize your process.

Things To Consider When Using Octopus

There are numerous ways you can configure Octopus. Like coding, some ways are better than others. In a lot of instances, after you have set your Octopus process up once, you won't touch or think about it much after it's done, so 'best practice' is probably less important here than it is in your development process. There are a few considerations you should make up front. In this section, I'll hopefully cover some of them.

One of the main considerations you'll need to make is what you'll want to keep in source control and what you want to move into Octopus. Let me explain. When you start to implement your continuous deployment set-up, at some stage, you will need to add to use some variables to configure different settings for your different environments.

I've seen some companies who have everything as Octopus variables. These include all connection strings, app settings, the whole nine yards. Personally, I wouldn't recommend you go down this path. From experience, in theory, this sounds like a great idea, in practice, the poor sod who has to set it up will have a tedious few days on their hands.

If you have read any of my previous posts about deployment configuration, I've always recommended using transforms, with Octopus it's no different. When you use Octopus, it might be tempting to stick all your configuration into variables and have everything configurable within Octopus, but that approach definitely has a few downsides. First, if you want to add or test your config, you have to build your solution, have your CI tool to run it, and then wait for Octopus to deploy it.

On a big project, a build might take 5-10 minutes. If you need to add, or modify a handful of variables, you can easily find half your day has gone while you wait for things. If you stick with transforms, you can use a tool like Slow Cheeta to quickly deploy your work locally. Sense check it first and then when everything looks like it works, check it in and wait for the build server and Octopus to do its thing.

Even though this process sounds really simple and obvious, a lot of people don't consider it the first time they start using Octopus. A transform route is generally quicker. You will also need to think of traceability and logging. If you have all your configuration in Octopus variables life might sound easy. You can log into Octopus, make a config change and then hit a button to deploy, all without opening Visual Studio!

The downside of this is, however, anyone can log into Octopus, change a variable and then break the build. Octopus doesn't have a rollback method so it's really easy to break the build and then afterward spend several hours trying to figure out what's gone wrong.

I've definitely been guilty of going in and 'tidying up' or deleting empty variables in the past, that has resulted in me spending half a day fixing up my mess. The more configuration you have in source control, the less chance a developer can muck it up. If you have a peer review process where no code can be checked into source control before it's been reviewed by anyone else, this double-edged authentication will make it close to impossible someone will accidentally break the build.

Unfortunately, from my experience, you don't have this in Octopus. My last point is around how you add Octopus variables into your code. This paragraph won't apply to the majority of readers, but it is a consideration you should probably consider. An Octopus variable will look similar to this #{variable} and in most companies, you would create a config file for each environment. Add your Octopus variable placeholders in source control and then check it in to let Octopus do the work.

One client, the main focus wasn't the website, so the continuous integration process was set-up around an API architecture. Instead, they used PowerShell scripts to effectively do a find and replace on all config files that they wanted to get transformed. The PowerShell script was run after the CI build and would inject the Octopus variable names via script.

I haven't run into any other company that's adopted this approach yet. It definitely did work, but it's another consideration of timing. Instead of having all your config in one file and your Octopus variables, you also had to think and maintain a third-party script in team city. Testing this script again, involved checking the files in and waiting for the build server. So, on one hand, the project didn't have any reference to Octopus in source control.

All Octopus work was done on the build server, so the source code was completely unaware of any transforms, had no Octopus placeholder within it, everything happened in effect after you checked the code in that could happen later. This meant everything was configurable in the cloud. Again, it worked, but it added time creating the PowerShell script, maintaining it.

Episerver Licensing

Having said all of the above, I would recommend that you put your Epi licenses as a variable. From experience, this has made life a little easier with onboard new people and adding new environments. The main reason for this is that in some companies, the IT Infrastructure team are responsible for licensing, so having everything in Octopus compared to config means that people who don't know GIT, or have Visual Studio, can easily log into Octopus and refresh licenses etc.. Within your license file, you can add an Octopus variable like #{EpiserverLicense} and then let Octopus sort it out for you.

I'm hoping this issue raises the point, you can configure Octopus to do whatever you want. It will work all through transforms, or everything in Octopus. The overriding question you need to think about is who should have access to update things and how much added time do you want to add into your deployment process set-up to provide this flexibility. In general, the more power you put in Octopus, the longer the set-up time becomes.


My recommendation is to follow a process that allows you to keep as much of your configuration as possible within source control. The source has been around for a long time and everyone knows how to use it nowadays. The message I tend to preach to companies is that source control is king. It provides you not only with a rollback strategy, but it also gives you traceability to see who did what. An added benefit is it will also reduce your continuous integration set-up time.