During development, your team makes a lot of changes to fields, templates, presentation details, and various other elements that need to be tracked, verified, and deployed. You need a way to source control those database changes, and then make them available to your team to test. Here’s how to accomplish that using TeamCity and Team Development for Sitecore (TDS)!
Sitecore content items in source control
Our teams use Team Development for Sitecore from Hedgehog Development to create .NET TDS projects to source control the changes we make in the Sitecore database. There’s a great guide from Hedgehog to start with, and I’ve also just written a post on some project configuration basics.
Automating deployments of Sitecore content items
With your content items now in Source Control, you can start getting your database changes deployed along with your build.
Note: This assumes you are automating your file deployments to push code changes out to your environments. If you aren’t yet, you should be! Look for my upcoming posts on setting up deployment build configurations.
In order to get TeamCity to be able to deploy, there are a few things you need:
- Install TDS. The TDS software needs to be on the build server where TeamCity is installed. This does not require an additional license to be purchased as Hedgehog allows your build server to be covered under your existing developer licensing. (Check their FAQs for details).
- Configure Build Settings. Your TeamCity build configuration needs a few parameters in order to ensure the content items are deployed to your review environment.
- SitecoreWebUrl: This specifies the URL of the website you want to update. For example: http://dev.mydomain.com.
- SitecoreDeployFolder: This specifies the UNC path where the Sitecore website folder is located. You should set up a share to push to if the website folder is on a network server separate from the build server (recommended!). For example: //mydevserver/Website
Your Command line parameters on your build step should look something like this:
/p:IsDesktopBuild=false;GeneratePackage=false;RecursiveDeployAction=Delete;SitecoreWebUrl=http://dev.mydomain.com;SitecoreDeployFolder="\\mydevserver\Website"
Publishing after deployment
There are several ways to accomplish this, including using Sitecore Rocks, but we have done this by setting up an ASPX on our internal Sitecore sites to execute a publish. The build configuration has a step with a Powershell call to trigger this. Using TeamCity build steps you can configure a trigger using a Powershell call to the publishing page.
TeamCity Configuration
The configuration for TeamCity uses an additional build step after you’ve deployed files and TDS:
- Runner Type: Powershell
- Step name: Trigger Publish to Web DB
- Powershell run mode: x64
- Working Directory: [no value]
- Script: Source code
- Script Source:$r = [System.Net.WebRequest]::Create(‘http://mywebsite/SomePath/Publish.aspx’); $resp = $r.GetResponse();
- Script execution mode: Put script into Powershell stdin with “-Command -” arguments
Publish.aspx
The code for our Publish page is something like this:
string full = Request.QueryString["full"];
// Set up the publish mode
PublishMode publishMode = PublishMode.Smart;
if (!string.IsNullOrWhiteSpace(full) && (full == "1" || full.Equals("true", StringComparison.InvariantCultureIgnoreCase)) ) {
publishMode = PublishMode.Full;
}
using (new Sitecore.SecurityModel.SecurityDisabler()) {
//We need the target database
var webDb = Sitecore.Configuration.Factory.GetDatabase("web");
//source db
var masterDb = Sitecore.Configuration.Factory.GetDatabase("master");
try {
foreach (Language language in masterDb.Languages) {
//loops on the languages and do a full republish on the whole sitecore content tree
var options = new PublishOptions(masterDb, webDb, publishMode, language, DateTime.Now)
{RootItem = masterDb.Items["/sitecore"], RepublishAll = true, Deep = true};
var myPublisher = new Publisher(options);
myPublisher.Publish();
}
}
catch (Exception ex) {
Sitecore.Diagnostics.Log.Error("Could not publish the master database to the web", ex);
}
}
But I don’t use TeamCity?
The concepts above can apply to almost any build server, be it Jenkins, TFS, or other. In an upcoming post I’ll discuss how to configure this for TFS.
St-Cyr Thoughts 
Leave a reply to Robbert Hock (@kayeeNL) Cancel reply