With the release of TDS 5.5, deployments now support post-deploy actions with a few out of the box options. However, you can even add your own custom actions into the flow. With a little help from Hedgehog Sitecore MVP Sean Holmesby (Thanks Sean!), I was able to get this working using the following six easy steps.
Team Development for Sitecore (TDS) supports the ability to manage your Sitecore roles within your TDS projects in Visual Studio. This ensures that important roles defined for things like workflow or other security needs can be deployed to all your environments.
Recently, I was building my packages for deployment to production and was going through the generated .update package and could not find my roles. No folders for roles, no files for roles… WHERE ARE MY ROLES?
Hedgehog support to the rescue!
I reached out to the fine folks at Hedgehog for some help and heard back the same day. Apparently, the standard Sitecore Update package format doesn’t support roles, so when Hedgehog added the support they did some sneaky things to make magic happen. The roles have actually been added into post deployment steps, and you can find the role definitions inside the file /_Dev/DeployedItems.xml.
The XML looks something like this:
<Role Name="sitecore\Keystone Multisite Manager"> <![CDATA[LS0tLXJvbGUtLS0tDQpuYW1lOiBzaXRlY29yZVxLZXlzdG9uZSBNdWx0aXNpdGUgTWFuYWdlcg0KDQo=]]> </Role>
This obfuscated CDATA content contains all the things you need to define the role in Sitecore. Pretty nifty!
Recently I needed to get builds running in Visual Studio Online (VSO) that contained Team Development for Sitecore (TDS) projects. Since I cannot install the TDS software on the VSO build server, I needed another way to get these projects to compile with a VSO build definition.
The following blog post has very detailed instructions on how to change your TDS project to use Hedgehog DLLs and a license file within your source control and helped immensely:
The referenced post indicates that you should update a file named TDSLicence.config in order to provide your TDS licence key. This file does not exist by default, so you will need to create it. The file name is important! I accidentally created the file with the American spelling ‘TDSLicense.config’ and the build server was unable to validate the file. Hedgehog support helped me out by pointing out my typo, but also explained that version 5.1 and up will support both spelling variations.
C:\Program Files (x86)\MSBuild\12.0\bin\amd64\Microsoft.Common.CurrentVersion.targets (990): .NET Framework v3.5 Service Pack 1 was not found. In order to target ".NETFramework,Version=v2.0", .NET Framework v3.5 Service Pack 1 or later must be installed.
Local compilation with Visual Studio looked fine and the build server was able to complete successfully if I excluded the TDS projects from the build configuration. This pointed to a problem in the TDS projects themselves.
Further investigation yielded that this is a TargetFrameworkVersion issue within the XML of the TDS project files. In my scenario the project files had a value of:
If the build server only has the most recent .NET assemblies installed, it will not be able to compile this project. Luckily, there are 3 easy steps to fix this for any TDS project file:
- Open up the .scproj file for manual editing with your favourite text editor application.
- Change <TargetFrameworkVersion>v2.0</TargetFrameworkVersion> to <TargetFrameworkVersion>v4.5<TargetFrameworkVersion>
- Save the project file.
NOTE: You may have to repeat this multiple times within a single project file. I noticed that my particular TDS project had two instances of the TargetFrameworkVersion tag in the XML!
Over the last few years, I’ve been trying to iteratively improve our own processes at nonlinear to deliver better Sitecore solutions and set our clients up for maintainable and sustainable ALM processes. Some of my posts on automated Sitecore deployments with TFS or TeamCity outlined some of the initial steps we took in automated deployments. Recently, we posted a brief series to help folks getting into Application Lifecycle Management:
The first new piece of content I put together on this was a slideshare introducing ALM concepts of tool and process improvements, just to get people thinking about where they are in the process and what they need to change. I also covered how to achieve this with continuous improvement model, instead of trying to do a big-bang delivery.
The second piece I wrote covers why ALM matters for Sitecore (and pretty much any web application). The post covers some of the primary benefits of ALM, as well as how to apply ALM processes during your Sitecore implementations.
The third piece, written by my colleague Mauro, highlights some tips for automated testing of Sitecore implementations, specifically with Selenium. He’s been doing some really awesome things with automated testing of Content Editor, Page Editor, and the end-user flows.
The recommended reads:
Have you encountered a failure while executing an automated Sitecore deployment with TDS where the type initializer throws an exception and you are asked to reinstall the TDS application? Apparently, if your TDS installation becomes corrupted somehow, you need to get rid of the web service and let TDS reinstall itself. This might occur if you upgrade versions, at least, it did for me! Here’s how to handle the issue…
Have your deployments to Sitecore 6.6 installations been taking a very long time? Do your build logs show 3-4 seconds for every template item that is deployed? Are you seeing the following warning in Sitecore logs?
All caches have been cleared. This can decrease performance considerably.
If so, you are probably running on an older version of TDS. I recently ran into this problem with our TeamCity installation that was using TDS 126.96.36.199 to execute deployments. Simple deployments were taking over 30 minutes, sometimes up to a full hour. We brought that down to 5 minutes or less by simply upgrading to the latest version of TDS.