Implementing Continuous Deployment With Umbraco
Wed 14 December, 2016 / By Jon D Jones
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 bugs and errors making it onto your live website, it will also free up a lot of developer time, which allows people to focus on solving business needs, rather than worrying about messing around copying files in-between servers. A lot of developers still seem to get confused about how to setup continuous deployment, so in today's guide, I'm going to cover what a good continuous integration process with deployment looks like.
Continuous Integration With Umbraco
To have an automatic build process, you would have a build server, such as Cruise Control or TeamCity, to integrate with your source code repository, whether it be Git, TFS or SVN to take the committed code and build the application. If you are new to all this, then CCNet (Cruise Control) works and is free although the functionality is a bit basic. Team City is easier to use and more flexible but does have fees as it's a commercial tool.
A good continuous integration on check-in will automatically run unit and integration tests within your solution that will be automatically triggered to test that everything works. Stylecop can be configured to run to ensure code meetings your coding standards. If the tests pass the application builds and deploys, if the tests fail then the commit will be cancelled. The next evolutionary step in this process is to the build server for deployment into production environments as well.
The thing that gets built by the deployment server depends on your needs. In some environments, I've configured the build server to simply copy all the files, in other environments, the build server has created Web Deployment Packages that are easily scriptable for deployment.
The automatic file copying process is called continuous deployment. In my opinion, continuous integration and deployment should be your preferred method of deploying an Umbraco website. 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, then you are doing it wrong. Any process that is reliant on human best intention will break once in a while.
After implementing a continuous deployment process, deploying a new version of your website becomes much less scary than if you do it seldom and manually. You can create your own MSBuild scripts to do the continuous deployment part, but there is a really good deployment software available called Octopus that I recommend you look into.
The last part of the puzzle that I've yet to mention is Transforms. I think everyone reading this will understand the need for a website to have different settings for the different servers, a good example is your SQL connection string. A staging website will point to a test database so you can play around without breaking anything, your production website will point to your live website.
As part of the build process, a build server will perform transforms to your key config files, like web.config, connectionstrings.config and umbraco.config and copy in the appropriate enviroment settings. Transforms are performed when publishing the project, not when building and is the key part of making your life eaier. No more worrying about different config files. You now have everything built for you and configured correctly, automatically!
What Is Octopus?
Octopus takes the deployment packages that the build server prepares and installs them in the target environments. You configure Octopus to automatically change the environment settings required for each environment, what web sites to create, where to deploy etc.. Octopus then creates a form of NuGet package that can be installed.
Depending on your level of risk will depend on where you build. Some companies will only do continuous deployment into dev, test and stage environments. Others companies are happy to deploy into production as well, but you need to get agreement about your acceptance testing.
In the later half of 2016 Umbraco Cloud came out. Umbraco cloud takes a lot of the issue of traditional hosting and deployment away. With Umbraco cloud you simply commit 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 to my clients. 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 set up to get a continuous integration plan up and running and it's one of the reasons a lot of developers put off doing it. A week or two is not uncommon to get this 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 up front. 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!