In the tutorial, you will learn why you should consider Octopus deploy when setting up your build pipeline to work with an Episerver CMS power website and how to configure it for optimal use. Having a good Ci/Cd pipeline is an essential step for any professional organization, especially when you are building an enterprise-level website powered by Episerver CMS. If you are reading this and you are on the fence about 'wasting' time implementing continuous integration and deployment then PLEASE trust me, it is worth every second. You'll be saving your company months' worth of time and money. You will also reduce the number of bugs that make it into production! Speaking from personal experience, if you can be the person who introduces an automated deployment process, your company/client will appreciate you 😁.
No matter how many features you build, if you can introduce a system where you can roll back bad deployments with a click of a button and reduce the risk of a company's website being down you will be known as a legend 😎. In a retail setting, having a site that is down for 30 minutes can cost a company thousands in lost revenue. As a developer, you might not consider being a pipeline guru as part of your development responsibility. Some developers think pipelines should be handled by the infrastructure team, or, pipeline stuff is too hard. Do not be that guy. Understanding this stuff 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.
As a long time contractor, it's not uncommon to come into a client's office to learn the deployment process is copying a handful of DLL's onto servers. From my experience, every time I have encountered this set-up, not having a pipeline 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 that I have spoken to about it has been positive, so it's a good choice. Your next step then is to decide how to set up Octopus to work optimally with Episerver CMS.
I think the first goal for setting up a continuous integration and deployment pipeline, is to first sit down and design what you want to happen. Sure it is important to get something working, however, a good deployment strategy can save you hours' worth of trial and error fixes compared to simply hacking away. 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.
There are numerous ways you can use Octopus to deploy a website. Like coding, some ways are better than others. Often developers worry about doing things the best way, however, after you have set your Octopus process up once, you won't touch or think about it much after it's done. Best practice in your Ci/Cd is probably less important than it is in your code.
Things To Consider When Using Octopus
One of the main considerations when setting up your pipeline is to decide 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 companies that store every single configuration value within Octopus variables. These settings include all connection strings, app settings, the whole nine yards. Personally, I do not recommend this. From my 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 Octopus variables, however, that approach definitely has a few downsides. First, you won't be able to test your site locally at all. The only way to test the site is to deploy it using Octopus. This will create a very long-winded dev, deploy, test cycle. If have to use your CI tool to test every change, you will be waiting a lot. 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 just waiting. If you stick with transforms and values in your solution, you can use a tool like Slow Cheeta to quickly deploy your work locally, sense check that it works before you 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 how do you track when things get updated? Any developer can log into Octopus, make a config change and then hit a button to deploy, all without opening Visual Studio! This process bypasses code reviews and it can be hard to revert changes! Using Octopus variables too much can result in frequently broken builds.
I've definitely been guilty of going in and 'tidying up' or deleting empty Octopus variables. My good intentions have resulted in a broken pipeline and wasted time trying to revert my changes. Unfortunately, from my experience, you don't have a way to easily revert changes in Octopus. This is why I prefer adding all my values in config so the site works locally and then using Octopus to override key settings during the build. This approach is more efficient, however, it will require you to do some Octopus variable substitution using a custom script on the server.
An Octopus variable will look similar to this #{variable}. Adding Octopus variable directly in your config files is easy enough, however, this will mean you can not run your site locally to debug. Instead, if you want to run your site locally you will need to write some custom PowerShell scripts to effectively do a find and replace on all config files to replace and inject the Octopus variables during a build on the build server. To learn how to do that read this article. The downside of this approach is that you have to maintain these extra scripts. Testing these scripts can also be longwinded. The process will involve updating the script in Octopus, kicking off a build and waiting for the build server to run. Having all Octopus references on the build server does give a nice separation of concerns. The source code is completely unaware of any Ci/Cd configuration. Everything happens after check-in and committing the code.
As you can see there is no perfect solution to Ci/Cd. I prefer the custom script approach, however, both have pros and cons. You will need to decide which route is better for you 🤯. Below gives a list of things that I recommend you store within an Octopus variable:
Episerver license: From experience, this has made life a little easier to onboard new people on the project and when adding new environments. In most companies, the IT Infrastructure team are responsible for licensing, so having license data in Octopus means infrastructure people who don't know GIT, or have Visual Studio, can easily log into Octopus and refresh licenses
Secrets: I recommend that you store all passwords secrets in Octopus variables. File share username/passwords, connections string details. These values seldom change and hiding them in Octopus is good practiceI'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.
The main theme of this tutorial is to consciously decide which data lives where. What should be in Octopus and what shouldn't? The two main approaches outlined, transforms and Octopus variables, both work. The overriding question you need to consider when setting up your pipeline is who should have access to update things and how much added time do you want to invest to allow 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 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. Happy Coding 🤘
