In this tutorial, you will learn how to build a Ci/Cd pipeline for a website powered by Umbraco CMS. Nowadays, it seems like one of the first things that I do when I start working with a new client is help them introduce a continuous deployment process. Being able to automate your deployments will not only help reduce the number of accidental configuration bugs making it onto your live website, but it will also free up a lot of developer time. When developers can focus more time on solving business needs, rather than worrying about messing around copying files in-between servers, companies tend to make more money 💰 💰 💰. A lot of developers still seem to get confused about what steps are needed within a continuous deployment pipeline. In today's guide, I'm going to cover what a good continuous integration process looks like when you use Umbraco CMS to power your website.
Continuous Integration And Deployment
There are a few ways to set up a Cid/Cd pipeline. The most common one is to build everything yourself To have an automatic build process, you will need a dedicated Windows server that is running a bulid server. There are many different vendors who create build management and continuous integration software. Common products include CCNet (Cruise Control) and TeamCity. CCNet is free although the functionality is a bit basic, Team City is a paid-for product, however, it is easier to use and more powerful. The job of the build software is to integrate with your source code repository. This can be Git, GitLab, TFS or SVN. The build software will listen to your repositories for new pushes. When a new push occurs, it will take the committed code and build the application. It will be up to you to define a build pipeline within the build software. This pipeline defines the steps the build tool will follow when building the code. You might want the pipeline to trigger the unit tests before it pushes the compiled code onto a server in a later step
A good continuous integration process will fire automatically on every commit. The pipeline will make sure the project compiles successfully and that any linting rules are followed. After successful compilation, it will automatically run unit and integration tests to test that everything works. If the tests pass, the pipeline then copies the files with the correct configuration values onto the server where the website will be hosted. If any of the tests fail, the commit will be cancelled.
There are a few techniques to define how files are copied onto a server. In some pipelines, I've configured the build server to simply copy all the files, in other environments, the build server has created web deployment packages. A web deploys package bundles all the files into a single executable file. This single file can be triggered on the server to deploy the new files.
The pipeline can also be configured to do all of this automatically or manually. You can configure the pipeline to build and deploy all changes to the
master branch. When you set up everything to work automatically, this is called continuous deployment. In my opinion, continuous integration at a minimum should be your preferred method of deploying a Umbraco website. If you have lots of unit tests and integration tests, continuous deployment is possible in production. Without all these tests, continuous deployment is risky! This is why most teams only do continuous deployment to a dev server only!
Continuous integration also encourages small incremental deployments that take place every time you change something in the code. If you want to create a robust and foolproof deployment method you should invest some time implementing a continuous integration process. If your deployment process involves any kind of manual file copying, you are doing it wrong. Any process that is reliant on human best endeavours will break once in a while. After implementing a continuous deployment process, deploying a new version of your website becomes much less scary and more importantly, quicker 🏃🏃You can create all of your own MSBuild scripts to do the continuous deployment part, however, some really good deployment software called Octopus deploy that will make managing deployments less painful.
The last part of the puzzle that I've yet to mention is configuration. Each server will require different configuration values. The process of using the correct values within the pipeline is done using transforms. A good example of a different config between development and production is the SQL connection string. Development and production will need to have their own unique database instances. If the build pipeline used the same SQL value this would be problematic! As part of the build process, a build server will perform transforms to your key config files, like
umbraco.config and copy in the appropriate environment settings. Transforms are performed when publishing the project. If you use Octopus, you can store values in Octopus variables. Using Octopus variable syntax in your config files will ensure the values are substituted when Octopus deploys the code. Transforms are the key part of making your site work on different servers. No more worrying about different config files.
This explains why we have continuous integration (something happens on the source control commit) and continuous deployment (files are copied somewhere). Team City makes sure the files are correct. Octopus takes the deployment package created by Team City and installs the files on a target environment. Simples 🌈🌈🌈
I promised that this tutorial was about Umbraco and I have yet to mention it. As you can see setting up servers and managing pipeline takes time, effort and specialist knowledge. Would it not be great, if we can get all of these benefits with just a few button clicks? In the latter half of 2016, Umbraco Cloud came out. Umbraco Cloud takes the hassle of setting up and managing a server and creating a Ci/Cd pipeline away. Umbraco Cloud will set everything up for you including the Umbraco installation, source control set-up, server and Ci/Cd pipeline. You simply commit your latest changes into GIT and your work is copied to your live host. If you're starting a new Umbraco project, this is the hosting and deployment strategy I'm advising my clients to use. If you want to know more about Umbraco Cloud, I've written a guide that explains everything you need to know, Umbraco Hosting.
As you can see, there is quite a bit of stuff to learn before you can get a good continuous integration pipeline up and running. This set-up pain is one of the reasons a lot of developers are put off doing it. A week or twos worth of solid development effort is not uncommon to get a pipeline working. The quickest and easiest time to introduce a continuous integration process is at the start of a project, however, typically it usually gets overlooked. Trying to add it in later is doable but it adds a lot more risk and effort than doing it upfront. If you are starting a new project then I would recommend trying Umbraco Cloud. If you still want to use traditional hosting then my main advice is to use Team City and Octopus and do it at the start of the project, not after the CEO is shouting that a deployments gone bad! Happy Coding 🤘