Sitecore Continuous Integration with Team City and TDS

CIProcess

There are a lot of articles around on how to do automated deployments / continuous integration with Sitecore, which if you’re new to the tools will likely leave you slightly baffled. This article will hopefully show you exactly what you need to do and explain why.

Solution Overview

  1. TDS is used by developers to serialize their Sitecore item changes and push them into source control
  2. Team City is used to detect the changes and run a build script
  3. Team City uses Web Deploy to push the code changes to the web server
  4. Team City calls MSBuild which will trigger TDS which is installed on the server to deploy Sitecore items to the destination server

Prerequisites

  • You have a build server with Team City installed and know how to set it up to do a web deploy
  • You are already using TDS and have your Sitecore items serialized in source control
  • Essentially you know how to do the first 3 steps and just need help with Step 4

Step by Step

UNC Share

On your web server you need to set up a UNC Share on your website’s folder. When TDS does a deploy it will install a web service on your website through this share, do the item deployment and then remove the web service again.

The share needs to give permission to the user that your Team City Build Agent runs as. To find out which user your Build Agent is using:

  1. open the list of services and find TeamCity Build Agent in the list
  2. right click and select “Properties”
  3. in the “Log On” tab you will be able to see which Windows User is being used

Team City Config

In your Team City’s build configuration settings for your project, add a new build step with the following config:

Runner Type: MSBuild
Step Name: Publish TDS Items (or some other identifier)
Build file path: Path to your projects .sln file
Command line parameters:

  • SitecoreDeployFolder: TDS will use this file path to install a web-service on your site to publish the items through.
  • SitecoreWebUrl: This is the url of the site you are going to update. TDS will use this when it tries to call the web service it installed.
  • IsDesktopBuild: false
  • GeneratePackage: false
  • RecursiveDeployAction: Delete
/p:IsDesktopBuild=false;GeneratePackage=false;RecursiveDeployAction=Delete;SitecoreWebUrl=URL OF SITE;SitecoreDeployFolder="UNC PATH TO YOUR SITECORE SITE"

Setting the command line parameters here will take precedence over any that have been included in your TDS projects solution file (which are liable to be overwritten by a developer).

TDS Build Settings

That’s it!

It’s that easy. If you run your build script now your items should all be published to Sitecore.

Alternatives

This certainly isn’t the only way to setup automated deployments and nor is it without issues. The fact a share needs to be set up between the Web Server and the Build Server, could cause an issue with security and may just not be possible if you’re using a cloud server.

Rather than using TDS to deploy the Sitecore items you could use TDS to create a .update package. These would normally be installed through an admin webpage (not great for CI) but there is an open source project called Sitecore Ship that will expose a REST endpoint for the package to be posted to. Brad Curtis has written an excellent guide to this setup here (http://www.bradcurtis.com/sitecore-automated-deployments-with-tds-web-deploy-and-sitecore-ship/), however at the time of writing Sitecore Ship isn’t compatible with Sitecore 7.5 or 8.

Another alternative to installing the update package is to use the TDS Package Installer. This is a tool Hedgehog provide alongside TDS for installing the update package. In this scenario you would need the tool installed on your web server and some way to call it. Jason Bert has written a setup guide for this example (http://www.jasonbert.com/2013/11/03/continuous-integration-deployment-with-sitecore/) however as well as Team City, you will also need Octopus Deploy to call the package installer. Octopus Deploy works by having what it calls Tentacles on each server you deploy to, making it easy to set up scripts to call programs on that server.

Sticking with the example using just TDS, you could also use TDS to deploy the solutions files as well as Sitecore items rather than using Web Deploy. However the downside here is that TDS is unable to modify your Web.Config file, which is one reason to stick with Web Deploy.

Advertisements

5 thoughts on “Sitecore Continuous Integration with Team City and TDS

  1. Derek Dysart says:

    Any reason you’re passing the deploy folder and web URL on the command line as opposed to having them in a build config? (I actually didn’t know they could be passed on the command line)

    • timgriff84 says:

      No outstandingly great reason. You could do it either way.

      At the time I was writing the post I did the setup with an existing solution that was sitting in our source control. Using a build config file would have meant altering what was in source control.

  2. Abhishek Shrivastava says:

    This was really helpful. Thank you.

    Sharing some of my experience:
    1) Make sure ALL the TDS projects “Build” and “Deploy” checkbox is selected in the Build Configuration. Otherwise, Sitecore items will not be deployed.

    2) For all TDS projects in the solution, ensure “Sitecore Access Guid” is same.

    3) In case you receive exception “Reason: The TDS connector is not the correct version.”. Make sure the TDS version is same in TeamCity Build server and all the environment.

    4) In case TeamCity is throwing exception: “The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.”
    I did the following:
    a) For the TDS projects, under General settings, Make sure the “Source Web Project” is . Since we found it unnecessary to build Web Project when building TDS project.
    b)Also in some cases, if need be you can change the “Agent Work Directory” of TeamCity to the root of your drive. Agent Build Directory is the directory that TeamCity build agent used to checkout the directory from source repository. More information is here: https://confluence.jetbrains.com/display/TCD8/Build+Agent+Configuration
    In my case, I changed workDir parameter to “workDir=C\:\\X” in “C:\TeamCity\buildAgent\conf\buildAgent.properties”

    5) The TeamCity Build agent account MUST have the read/write permission on the Website root for which UNC Share is setup.

    • Abhishek Shrivastava says:

      Type: Corretionfor 4) a, For the TDS projects, under General settings, Make sure the “Source Web Project” is NONE . Since we found it unnecessary to build Web Project when building TDS project.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s