TIHIDI: Continuous Integration for a Sitecore solution – Engage!

This blog post will go through how I setup my solution in a Continuous Integration environment. A true Continuous Integration and Delivery environment would need very little human intervention.

The Continuous Integration setup should trigger a build for each check-in and deployed to the Dev environment by default. Deployment to other environments should be on demand and controlled.

Previously I have used Team City and Jenkins to do automated builds. In this blog post we will only talk about the Build process using VSTS (Visual Studio Team Services).

Although I have only been using it for a year, I love VSTS. It has a lot of integrations and is very flexible.

TIHIDI: Stands for This Is How I Do It. I am going to write a series of blog posts going through how I do Sitecore related work. Hope it helps you!

A vent about source control: We have all used Team Foundation Server (TFS). It used to be a great tool back in the day but with the amount of collaboration of teams across time zones, Git is where its at. Git wont bite you.

Once you get used to using Git, its fairly simple. With tools like SourceTree, Git Extensions and more, its very convenient.

First, get to https://www.visualstudio.com/team-services/ and get yourself an account if you do not already have one. Its free! You can host your Git repo to play with VSTS. There are a few restrictions but none that will block you for trying it out and even use it on your projects.

Once you have the account, create a project with a Git repo. Clone the repo and add your solution.

In your Sample solution, install the following on your .Web.csproj and .Serialization.csproj:

Install-Package OctoPack -Version 3.6.1

Once that is done, you would need to add a .nuspec file to define what gets packaged when OctoPack runs.

Here is the sample from my web project:

Here is he sample from my serialization project:

Notice in the serialization nuspec, we are specifying the exact files we need packaged up, where as in the web, we want it to capture the output.

Next, get to VSTS and create a build project for a Visual Studio Project. Here are the trigger settings so an automated build triggers on check-in. Be sure to check the “Batch changes while a build is in progress”.

Here are the steps in my definition:

Add a Get sources task and specify the repo and the branch. In this case I am pulling from the dev branch.

Add a NuGet restore step to restore the NuGet packages for your solution. Previously the NuGet restore was part of the Build Solution step but that is now deprecated.

Also I do some name attribute manipulation in the Nuspec file on the build server based on the environment we run on to generate NuGet packages with different names. This step has some PowerShell to replace content in the Nuspec files.

Add a Build Solution step to compile your solution and run OctoPack to push your generated NuGet packages to your Octopus server.

That is it. Our builds are done in less than 1 minute. The majority of time goes into uploading the NuGet packages to the Octopus server.

If you have any questions or concerns, please get in touch with me. (@akshaysura13 on twitter or on Slack).

Leave a Reply

Your email address will not be published. Required fields are marked *