We're building several "greenfield" Sitecore 8.1 web applications with TDS 5.5 used for synchronization of Sitecore Items.

We don't want developers to be required to do any extra work to deploy the .item files to our CI/CD environment (and preferably any deployment environment).

Instead we would like to execute something on the CI/CD environment that deploys the items. We're guessing that the build process may need to package them in some way for this to be achieved. We can't install Visual Studio on the deployment environments.

I've seen that from TDS 5.5 there is something about using NuGet to assist with this, but I can't find any step-by-step details.

Any ideas?

5 Answers 5


Alex, there are many ways to approach CI deployments into your environments. Each client or organization is going to have different requirements as it related to versioning, restoring of backup, downtime, server access, etc...

A link

Here is a great read that I think covers most of what you need.

TDS to Nuget

But we don't do just link answers here, so I will provide you with my personal experience. Here is how we did it recently at a client that has a requirement to use Jenkins, PowerShell, Nexus (for nuget storage).

  1. Configure the TDS projects to create an Update Package on build. (Update Package tab of TDS project)
  2. We created a job in Jenkins that used PowerShell to build the Visual Studio solution. Outputting the TDS update packages.
  3. Using the build number from Jenkins we versioned the outputted update package and pushed it to Nexus via the Nexus api. We now have a versioned package of the Sitecore items in Nexus (a type of Nuget server).
  4. We created another Jenkins job to deploy the package on the CM server, with a selector allowing us to specify a build number to deploy.
  5. When the job runs, the CM server downloads the specified nuget package from Nexus, and using Sitecore PowerShell Extensions (SPE), we install the package and finally publish the items to the CD server.
  6. If there are any deployment issues, we redeploy the pervious version to set the items back to how they we previously. You could also use SPE to create an anti-package and push that to NuGet before you deploy.

That is just one of many examples on how to deploy items via CI to your servers. As George stated, you can use Sitecore Ship to install packages, or SPE, or create an aspx page that pulled update packages from a folder that installs them via the Sitecore runtime. There are many ways.


You will need something to orchestrate the deployments. You can use:

Here is a recent Un-official Sitecore training that covers CI and Sitecore.

Here is a nice video on the overview of using Team City to deploy Sitecore by the nice people over at Hedgehog.

I hope this helps you

  • 1
    Your link to creating anti-packages only works for .zip packages. TDS generates .update packages so you should use this to create a rollback instead: jammykam.wordpress.com/2017/01/24/anti-update-rollback-package
    – jammykam
    Commented Feb 17, 2017 at 11:24
  • The only missing piece is: How does the TDS project produce update packages on build when TDS is not installed on the build server? Thanks for your answer so far - very helpful!
    – Alex Angas
    Commented Mar 16, 2017 at 7:49
  • You will need to install TDS, or at the least have the binaries in the file system, to have it build and produce the update packages.
    – Jason Bert
    Commented May 24, 2017 at 8:17
  • @AlexAngas teamdevelopmentforsitecore.com/Blog/…, TDS shows how to get around installing it manually on your server (including binaries and a TDSLicence.config file).
    – vandsh
    Commented Jun 20, 2017 at 11:37

You can have TDS generate an update package with all the Sitecore items and code, then use Sitecore.Ship or Sitecore PowerShell Extensions Remoting to install the update package.

Sitecore.Ship provides a web service to install update packages with - you typically use wget or something similar to stream the update file to the service. Anecdotally, wget hasn't been great especially dealing with large packages with lots of items. I've probably experienced every timeout known to man.

SPE Remoting allows you to use Windows PowerShell to use Sitecore PowerShell. Sitecore PowerShell has a cmdlet called Install-UpdatePackage that installs the update package from the Sitecore server. You'll want to copy the update package generated from TDS from the build server to the Sitecore server and call Install-UpdatePackage to install it. This can all be done with a ps1 PowerShell script.


You can generate the files and items packages using TDS, and then use the command line utility to install them on the server using Powershell script (you can use Octopus or other deployment orchestration tool to do that).


The advantage is that you can also install the package using Powershell manually on production and other environments where you don't have access to the deploymet orchestration server.


Since the Sitecore update packages been generated, using Hedgehog Sitecore Package Deployer is another easy way to deploy Sitecore items and auto-deploy/publish to CM/CD servers, especially if you can't install client service on servers such as Sitecore Ship. The Sitecore update packages are deployed as files to server folder, for example "$(dataFolder)\SitecorePackageDeployer". The deployer job runs on schedule to pick them up and process all the package one by one automatically.


You can achieve this in below simple ways:

  1. Install Sitecore Package Deployer from https://github.com/HedgehogDevelopment/SitecorePackageDeployer
  2. Disable the schedule job to deploy the items as mentioned in blog post.
  3. Add a step in Teamcity/Octopus or whatever tool you are using for deployment to build and generate update package and copy it to the path you have configured in SitecorePackageDeployer.PackageSource.
  4. Add another step to hit the webpage http://[serverUrl]/sitecore/admin/StartSitecorePackageDeployer.aspx

And you are good to go.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.