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 Team Foundation Server (TFS) 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 previously 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 TFS to be able to deploy, there are a few things you need:
- Install TDS. The TDS software needs to be on the TFS build server. Depending on your infrastructure, this may be the same machine that is hosting your source control, or you may be running the build agents on a separate build machine (recommended!) 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 TFS 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 build configuration Process section will look something like this:
1. Required 2. Basic 3. Advanced MS Build Arguments /p:IsDesktopBuild=false;GeneratePackage=false;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 an InvokeProcess action with a Powershell call to trigger this. By editing your build configuration template XAML with Visual Studio (or an XML Editor) you can add the InvokeProcess action to execute a Powershell call to the publishing page.
In our template, we use a custom argument named ‘PublishUrl‘ so that we can re-use the templates for multiple deployments and provide the URL to the publishing page in the build configuration. If you are only using the template for a single deployment build configuration, you can replace this custom argument with the explicit value of the publishing page. For example: http://mywebsite/SomePath/Publish.aspx
XAML Configuration – The XML
You can use the workflow process editor to add the InvokeProcess in Visual Studio, or add it directly with the following XML. The template used by the build configuration for TFS uses an additional action after you’ve deployed files and deployed TDS changes. Here is the XML that gets added to your template in order to invoke the URL:
<mtbwa:InvokeProcess Arguments="["&{$r = [System.Net.WebRequest]::Create('" + PublishUrl + "'); $resp = $r.GetResponse();}"]" DisplayName="Publish to website" FileName="powershell.exe">
<mtbwa:InvokeProcess.ErrorDataReceived>
<ActivityAction x:TypeArguments="x:String">
<ActivityAction.Argument>
<DelegateInArgument x:TypeArguments="x:String" Name="errOutput" />
</ActivityAction.Argument>
</ActivityAction>
</mtbwa:InvokeProcess.ErrorDataReceived>
<mtbwa:InvokeProcess.OutputDataReceived>
<ActivityAction x:TypeArguments="x:String">
<ActivityAction.Argument>
<DelegateInArgument x:TypeArguments="x:String" Name="stdOutput" />
</ActivityAction.Argument>
</ActivityAction>
</mtbwa:InvokeProcess.OutputDataReceived>
</mtbwa:InvokeProcess>
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 TFS?
The concepts above can apply to almost any build server, be it Jenkins, TeamCity, or other. I’ve recently posted about how to use TeamCity for Sitecore deployments, and in the future I’ll discuss how to configure this for Jenkins.
St-Cyr Thoughts 
Leave a reply to Chris Cancel reply