Sitecore DevOp Series – Part 7 – Setup Continuous Integration using Team City

This is part 7 of the blog series. Previously, we have installed a local instance of the Sitecore site, configured VS project, configured TDS, configured Sitecore Glass added our project to source control and congured DB and QA servers.

I am assuming that you have gone through the previous 6 parts and completed them as this blog post will depend upon them. I am also assuming that you have a brand new CI server with following applications installed:

  1. TeamCity latest stable version
  2. Visual Studio Community Edition
  3. Team Development Server for Sitecore (TDS)
  4. Chocolaty
  5. Git

This is a pretty lengthy blog and contains with lots of screen shots for every step of the TeamCity server configuration. If you get stuck at any point please look at the CI build logs, QA server logs and utilize Google to resolve your errors/issues.

The blog series is aimed at newer audience and developers who are setting up CI for the first time.

Step 1: Create TeamCity Project

Once TeamCity is installed, create your TeamCity project:


Once the project is created, you will have the ability to configure it with your source control:


Step 2: Configure with Source Control

Select ‘Create build configuration from URL‘ and give the source control URL of your project along with login details.


If your connection details are correct, you will see the confirmation screen like below:


Step 3:Configure Build Steps

Now its time to configure your build steps. The TeamCity will try to auto-detect your build steps:


If everything on the server has been configured correctly, it will configure the VS build step:


Step 4: Configure NuGet step and re-order

Create a new step by clicking on ‘Add build step’  and add a ‘NuGet Installer’  step type. Specify the path to the solution:


The build steps will be executed in the sequence they are ordered, so you need to re-order them. Click on ‘Reorder build steps‘ and put NuGet installer step before the VS build step:


If you are using any front-end frameworks, like Gulp or Grunt, you can also add a step for them using Node.Js as runner type.

Step 5: Configure Parameters

As we have added 2 steps, at this point we should test our CI server with only these 2 steps and try to fix any errors before proceeding further. Before we run the build, we need add some configuration parameters and tell TeamCity to use our QA publish profile so it can correctly transform the config files. The configuration parameters can be added in-line within the build steps but a better way is to add them as system parameters. Navigate to the ‘parameter‘ section to add parameters:


By clicking ‘add new parameters‘ a dialog box will show up, you can then add ‘System‘ parameters for your build as shown:


Repeat the process of adding new parameters and add all of the following parameters for your initial build. Update the system.username and system.password values relevant to your CI server. The system.PublishProfile should also be updated as per your VS project’s publish profile name:


Step 6: Run a Test Build

Click on the ‘Run’ button and test your build for the 2 steps that you have added:


I only had 2 steps, but I still got some errors on the first build which I resolved by looking at the ‘Build log‘ (like I missed a file to push to bitbucket and then my password was incorrect). After few attempts, I saw the green tick which was very re-assuring. So if your build fails for the first time, it’s OK, work through the build log and remove errors:


Step 7: Configure Sitecore.Ship

As of now, we were only deploying code files from VS with our 2 steps. But we also want to deploy our Sitecore Items generated through TDS update packages. By default, you can use TDS to deploy .update packages, however, there are other alternatives too. I am going to use an open-source module Sitecore.Ship which deploys update packages over http requests. The module should be configured as NuGet package with you main web project:


Once you install this, you will notice that there are some changes in your web.config files as well, check-in all of your changes and push them to the server.

Step 8: Configure TDS.Master

The next step is to configure TDS.Master to generate an update package. Navigate to MyProject.TDS.Master project’s properties, make sure the build mode is ‘Release‘ and update the settings as shown below:


Once you will build this, it will generate an .update package at a location bin/package_release

Step 9: Add a build step for TDS Master

An update package has been generated, now we want to deploy and publish this package along with our code to the QA server. We will be using curl to post HTTP request for update packages. Chocolatey is a package manager which can give us access to curl through its command line.

The deploy and publish step depends upon some configuration parameters. Navigate to parameters section and add the following configuration parameters:


Navigate to the build step section add a ‘command line‘ build step for TDS Master pacakges and enter the value for custom script as shown below: (update the project path relevant to your project)


Custom Script:

%curl.path% -i --insecure --show-error --fail --silent --form "path=@MyProject.TDS.Master\bin\Package_Release\MyProject.TDS.Master.update" %deploy.url%


Step 10: Run a test build for TDS.Master

There were few tools and configuration were settings introduced in the previous steps and to make sure everything works as expected perform a test build. If it fails, look through the logs and try to resolve issues. Some places where you also want to look are Sitecore Logs (in the data folder) on the QA server and website/temp folder on the QA server.

When I ran the first build, I got 500 error in the TeamCity build log for the TDS.Master deploy step. The error messages within the build log for Sitecore.Ship are not exact messages and may be misleading, you need to check the logs on the QA server for correct messages.

When I checked if Sitecore.Ship is installed and accessible fromm the CI server, I was getting 401 error:


and when I checked this from the QA server, I was getting everything is OK


When I checked the Sitecore logs on QA server, I got the following message


Which meant that I have to update the ‘allowRemote’ settings to ‘true’ in the web.config to allow remote package installation. The feature is disabled by default for security reasons. I also added IP address of the TeamCity server to the whitelist section and made my remote deployments IP protected:


Once checked-in and pushed to the server, I got some more errors related to missing folders and permissions.  I was able to resolve them by checking the logs and giving NETWORK SERVICE permissions to the folders.

Eventually, the deploy step succeeded and I was able to see Sitecore.Ship posting my entries from the CI server to the QA server:


This is great news, it means that when I check-in TDS items and related code, I do not need a package to update the QA server ‘manually’. I can just run the build and it will pick up the latest changes and deploy them.

Step 11: Configure a TDS publish step

The previous step has only deployed our update package. We also want to publish our package post deployment. We can configure a publish step through curl and Sitecore.Ship

Navigate to the ‘Build Steps‘ section and add another ‘Command Line‘ step for publishing. Add the custom script as shown below:


Custom Script:

%curl.path% -i --insecure --show-error --fail --silent --data '' %publish.url%

Run a test build to confirm it is working as expected.

Step 12: Configure TDS.Core and its build Step

One more step is to configure TDS.Core project with TeamCity server. We want our TDS project to generate an .update package for the TDS.Core project.

Navigate to MyProject.TDS.Core project’s properties and update settings as shown below:


Then add a ‘command line‘ step in Team City similar to the TDS.Master deploy step with following script (which only changes the path variable)

%curl.path% -i --insecure --show-error --fail --silent --form "path=@MyProject.TDS.Core\bin\Package_Release\MyProject.TDS.Core.update" %deploy.url%

Re-order the steps so you have core packages deploying before the master packages. Your build steps should look like below:

Depending upon your project and business requirements, you may want to add more steps like ‘Unit Testing’ or ‘Integration Test’ or other steps.

Step 13: Configure Triggers (Optional)

One optional thing to do is to configure trigger for the QA server, so that every time someone pushes the code to the source control, an automated build is started:


This is optional and you shouldn’t be configuring this step for the production environments

More Environments

The blog post only showed how to add build steps for the QA environment, but you may have a UAT environment, a staging environment and a production environment. You can repeat the build configuration process and add more automated deployments for each of your environment.

The steps mentioned here are only an example and meant to provide the basics of setting up CI integrations. Once you get comfortable, you can enhance number of steps and/or use different deployment strategies.

Final Thoughts

As you have seen, it took few blog posts to get the Continuous integration working, but once it is established, it will save you tons of time during the application development and even post-launch. If your organizations sets up projects frequently, the time to setup QA, DB and CI servers and local environments can be further reduced by using standard PowerShell scripts.

One final optional blog post about Slack notifications is coming up next few days and then it will be a wrap.


Related Blogs

  1. Part 1 – Continuous Integration – Why your Sitecore project deployments must be automated ?
  2. Part 2 – Setup and Configure Visual Studio Sitecore Project
  3. Part 3 – Setup and Configure TDS
  4. Part 4 – Setup Sitecore Glass
  5. Part 5 – Setup Source Control (Git)
  6. Part 6 – Setup QA Server, DB server and CI server
  7. Part 7 – Setup Continuous Integration using Team City
  8. Part 8 – Setup Slack Notifications with TeamCity and Bitbucket

Sitecore DevOp Series – Part 3 – Setup and Configure TDS

In previous blogs of the DevOp series, we have installed a local instance Sitecore and configured our VS for the sample Sitecore project. In this blog, we will add Team Development for Sitecore (TDS ) projects to our VS project. The blog series is aimed at newer audience and developers who are setting up CI for the first time.

Why do I need TDS ?

TDS is a great product for developing Sitecore projects. If you have not used it before, I would strongly recommend using it for your existing and new projects. The TDS seamlessly integrates with the Visual Studios and gives you a lot of options to manage Sitecore items. One of the main feature of TDS is that you can store Sitecore Items as serialized files on your local machine and push them to the source control repository. The development team can get the latest from source control, sync changes using TDS commands and update their local instance of Sitecore databases. This feature alone will save you and your team hundreds of hours development time.

The TDS can also automatically package up the data template changes for installations and deployments. It also gives you many more advance features for continuous integration which you can read on their official site.

Setup TDS Projects

Technically, you can have just one TDS project for your website and also configure it for continuous deployment. However, inspired from Pavel’s blog and personal experiences,  in this series we will be setting up the following 4 TDS projects

  1. MyProject.TDS.Core
  2. MyProject.TDS.Master
  3. MyProject.TDS.Master.Content
  4. MyProject.TDS.Master.System

TDS.Core project will be used to store any Sitecore’s Core database items like custom profile item or a new field type information.

TDS.Master project will be used to store Sitecore’s Master database items that are more specific to developers like templates, renderings, layouts, placeholder settings.

TDS.Master.Content project will be used to store Sitecore’s Master database items under the ‘Home’ node. If you have multiple sites, you can have multiple TDS.Master.Content projects, one for each site.

TDS.Master.System project will be used to store Sitecore’s Master database items under ‘System’ node. The ‘System’ node have items like ‘Workflow‘ or ‘Publishing Targets‘ or ‘Sitecore Powershell Scripts‘ that should be part of the source control, but we don’t necessarily need to deploy them every time.

All of the above TDS projects are optional and are meant for simplifying the deployment process as you will see in coming posts of the blog series.

Step 1 : Create TDS.Core project

Assuming that you have installed TDS for the correct version of your Visual Studios, right-click on the VS solution and click on ‘Add New Project’ and the select ‘TDS Project with Wizard’.

Give the project appropriate name like ‘MyProject.TDS.Core‘ and click on ‘Next’


On the next screen, set up the following parameters :

  • Sitecore Web Url
  • Sitecore Deploy Folder
  • Source Web Project
  • Sitecore Database
  • Check the install Sitecore connector

The example configuration is shown below:



Once you click Ok, a success message will pop-up and the new project should be added as below:


Step 2 : Create TDS.Master project

This step is similar to the previous one, except there is a small change when adding parameters on screen 2 of the wizard.

Right-click on the solution and click on ‘Add New Project’ and select ‘TDS Project with Wizard’. Give it the name as ‘MyProject.TDS.Master’ as shown below:


On the second screen, make sure to change the ‘Sitecore Database’ option to ‘master‘ and also un-tick the ‘Install Sitecore Connector’.


Click Ok and the project should be add to the VS solution:


Step 3 : Add TDS.Master.Content Project

Repeat the configurations for step 2, only changing name of the project



Same parameters as that of step 2, un-tick the ‘Install Sitecore Connector’ check box:


New project should be added on clicking Ok


Step 4 : Create TDS.Master.System Project

Repeat the configurations for the step 2, only change the name of the project



Same parameters as that of step 2, un-tick the ‘Install Sitecore Connector’ check box:


New project should be added on clicking Ok.


Step 5 : Get Sitecore Items

So now we have our TDS projects installed and we would like to populate these propjects with Sitecore items. When you will right-click on the ‘MyProject.TDS.Master‘ project and try to click ‘Get Sitecore Item‘ command, it will be disabled as shown below:


This is intended behavior as during setup of the TDS.Master project we left the ‘Install Sitecore connector‘ option un-ticked. If you have left it ticked during the project wizard, it will create a different Access GUID for each project which will be incorrect for our 4 TDS project setup.

Copy Sitecore Access GUID

As we have only installed the connector for TDS.Core project, we need to get the ‘Access Guid’ and copy it across to the TDS.Master Project

For this, right-click on the TDS.Core project’s properties and navigate to the ‘Build’ tab. At the end of the panel, you will find ‘Sitecore Access GUID‘ property. Select and copy that value


Paste Sitecore Access GUID

Navigate to the build tab of ‘TDS.Master‘ project’s properties build tab and now tick the ‘Install Sitecore Connector‘ box, a random GUID will appear. Delete that GUID and paste the same GUID as for the TDS.Core project as shown below:


Verify connection for TDS.Master

Once you have copied over the same GUID, click on the ‘Test‘ button at the end of the panel to verify the connection details. They should all be green as shown below:


Get Sitecore Items

Once you have ran the test, give it like 60 seconds and try to ‘Get Sitecore Items’ again, now all options should be available and you should be be to get Sitecore items as shown below:


If you select to add the standard ‘Sample Item’ template and all its children by right-click options, it should appear as below:


Repeat the Copy/Paste GUID process for TDS.Master.Content and TDS.Master.System


Once you have repeated the process for all TDS.Master.* projects and populated them with Sitecore items, your VS solution should look like this :


That’s it for now, in the next post we will configure Sitecore Glass Mapper, TDS with T4 templates and auto-code generation for the Sitecore data templates.

Stay tuned.



Related Blogs

  1. Part 1 – Continuous Integration – Why your Sitecore project deployments must be automated ?
  2. Part 2 – Setup and Configure Visual Studio Sitecore Project
  3. Part 3 – Setup and Configure TDS
  4. Part 4 – Setup Sitecore Glass
  5. Part 5 – Setup Source Control (Git)
  6. Part 6 – Setup QA Server, DB server and CI server
  7. Part 7 – Setup Continuous Integration using Team City
  8. Part 8 – Setup Slack Notifications with TeamCity and Bitbucket


Sitecore DevOp Series – Part 1 – Continuous Integration – Why your Sitecore project deployments must be automated ?

Over past few years with Sitecore, I have worked with various technical teams to deliver Sitecore powered websites. Sometimes we all are located in the same office, but most of the times, we are located in different offices and in different countries.

Part of my job role is to make sure that all of the development work is ready for testing (QA) at agreed time intervals (end of development sprint).

Quality Assurance (QA) is an important part of delivering any project and when a QA team member discovers a defect in the system, my usual conversation with the QA team member goes something like this:

QA : “Naveed, this feature is not working on the QA site?

Me: “Hey John (the fellow developer who did the original code), can you check why is it not working on the QA website?

John: “I am not sure, all my code is checked-in and it works on my machine as expected!

If you have worked on a Sitecore project, you must have had a similar conversation. The reason we have this conversation is because the deployment was done “manually”, which is an unreliable and error-prone process. A file or a package can very easily be missed during the deployment or a wrong version of a file can be deployed.

Moreover, the “manual deployment” process is very time consuming and it will increase the development cost. A typical Sitecore project may have numerous environments like QA, UAT and Production and each environment may have multiple CM and CD servers. As each server may be configured differently and may have different set of config files or config settings, the “manual” deployment process becomes even more complex. So you can see the “manual deployment” process, which started with one QA server, can quickly become very time consuming (read costly).

In an ideal world, what we would like for a Sitecore powered project, is that if someone has written a piece of code and/or updated Sitecore items, it should work on their local machine, it should work on the QA server (or any other non-production servers) and it should work on the production servers. The effort required should be minimal and nothing should be missed during deployment process. And for audit purposes every deployment should be documented.

Automated Deployments (Continuous Integration)

The best possible way to achieve this to make sure that the deployment process is fully automated from start to finish. All pieces of code and related Sitecore items should be packaged, deployed and published with “one single click” of a button.

To achieve our goal of ‘one-click-deployment’, there are tools and techniques available today (well actually since few years) which we can configure for continuous integrations and automated deployment. This will solve our 2 main issues:

  • Our deployments will be reliable and consistent.
  • We will be saving time and money.

If you are still doing “manual deployments” within your organization, it is time to re-think and re-evaluate this process.

The purpose of the blog series is to target newer audience/developers/tech teams, who have never done CI before and take them through a ‘hello world’ type of continuous integration process (automated builds).

Server Architecture

For the automated deployments to work, the code udpate workflow should be as following:

1- Developers should work locally and check-in their code in the source control (use of feature branches, fix branches and pull-requests is highly recommended)

2-Continuous Integration server  builds and deploys the code to the QA server

The diagram below shows a typical server architecture for the local and QA environment:



The important thing to notice here is that Sitecore items (templates, layouts, renderings, sub layouts) can be sourced control using tools such as TDS or Unicorn tools. I will be referring to TDS within the blog series.

As a minimum, automated deployment process for the above mentioned QA environment will require three servers :

1 – QA Server – Sitecore CM/CD combined on same instance

2- DB Server – Sitecore SQL server databases and MongoDB

3 – CI Server  – TeamCity server for continuous build and deployment

In theory, you can use only server, but it will have performance issues for the QA website.

Tools Stack

The tools stack that I will use to demonstrate the process in the series is as below :

  1. Sitecore CMS 8.2
  2. Visual Studios 2015
  3. SQL Express 2014
  4. Hedgehog Team Development (TDS) (licenses required)
  5. Sitecore Glass
  6. SlowCheetah
  7. Git
  8. TeamCity
  9. Chocolatey
  10. Sitecore Ship

There are other tools that can be used for the dev ops, for example, Jenkins can be used in place for TeamCity. Octopus Deploy can be used solely for deployment purposes, leaving CI server to do one job, that is to build the latest code. The decisions to choose the correct stack tools should be dependent upon your business requirements.

For simplicity purposes and for the newer audience, I will be using TeamCity for both build and deployment processes. Once you get confident with simpler process, you can enhance it/supplement it with different tools as you see fit for your project.

Assumptions for the blog series

I will assume that you starting a new project and have a blank machine/servers with only Windows on it or it is your first day at your new job. You can skip any of the below steps if you feel necessary:

  1. Download and install latest version of Visual Studios on your local machine or VM. At the time of writing this post, I have used VS 2015.
  2. Download and install latest version of SQL Express on you local machine or VM. At the time of writing this post, I have used SQL Express 2014
  3. Download and install TDS for VS2015 (requires commercial license, you can use 30 days evaluation for free)

I will also assume that you have RDP and FTP access to the QA, DB and CI servers as described in the architecture diagram to setup continuous integration.

As mentioned before, the blog series is intended for the  ‘new audience’, developers or teams who have never done CI integrations. The series will be pretty detailed and a single blog post will not do any justice, therefore it is divided into smaller logical parts of the setup process all of which will be posted in coming weeks.

The next part of the series are:

Sitecore DevOp Series – Part 2 – Setup and Configure Visual Studio Project

Sitecore DevOp Series – Part 3 – Setup and Configure TDS

Sitecore DevOp Series – Part 4 – Setup Sitecore Glass

Sitecore DevOp Series – Part 5 – Setup Source Control (Git)

Sitecore DevOp Series – Part 6 – Setup QA Server, DB server and CI server

Sitecore DevOp Series – Part 7 – Setup Continuous Integration using Team City

Sitecore DevOp Series – Part 8 – Setup Slack Notifications with TeamCity and Bitbucket


Local Sitecore Installation

Assuming it is a new project, the first part will be to install a blank Sitecore on your local machine. There are various options for installing Sitecore on your local machine

  1. You can install using the official .exe installer
  2. You can install using the official .zip file and attaching databases
  3. You can install using SIM module.
  4. You can install using Sitecore Rocks VS extension.

Every developer will have their preferred way for installing a brand new Sitecore website, I mostly prefer official .exe installer and will be referring to this in future posts as well.

Please refer to the official documents for installing the basic Sitecore website and do not forget to do the post-deployment steps.




For the purpose of the blog series, the project will be called ‘myproject‘. Once you have installed Sitecore locally and you can navigate the link http://myproject.local on your machine you are ready for the next step. By default, the installation location will be C:\inetpub\wwwroot\myproject\

In the next part of the series we will setup a VS project locally, configure a publish profile and add XML config transforms.

Stay tuned.


 Related Blogs

  1. Part 1 – Continuous Integration – Why your Sitecore project deployments must be automated ?
  2. Part 2 – Setup and Configure Visual Studio Sitecore Project
  3. Part 3 – Setup and Configure TDS
  4. Part 4 – Setup Sitecore Glass
  5. Part 5 – Setup Source Control (Git)
  6. Part 6 – Setup QA Server, DB server and CI server
  7. Part 7 – Setup Continuous Integration using Team City
  8. Part 8 – Setup Slack Notifications with TeamCity and Bitbucket