Yet another Hedgehog Team Development for Sitecore setup, from Developer Workstation to CI / CD Pipeline
Purpose
I have been using Hedgehog Team Development for Sitecore (TDS Classic) for Sitecore solutions for quite a number of years now, even before Unicorn was born. The later versions of TDS contain wonderful features like Delta builds, and designed with Helix solution setup in mind. The wonderful John Rappel has also made an extension using Git to generate a Delta TDS Package.
In long running Sitecore solutions, the number of Sitecore items that needs to be sourced control increases, and drastically slow down build and deployment. In this blog post, I will describe how I have setup TDS to work on developer workstations, all the way to the CI / CD pipeline to take advantage of Git Delta Deploy and minimise the size of the TDS Update Package, so that a build and deployment process becomes less TeDiouS (sorry I seriously cannot help myself).
Git Branching Strategy
There are multiple teams working on this code base, and our Continuous Deployment strategy requires the code to be pushed to different environments. The Git Branching strategy follows the Environment Branching Git Workflow.
The reason we are using this strategy is that a feature or bug fix branch can never be guaranteed to be released in the next release cycle. Working in an Agile environment also means that when a feature is completed, tested and reviewed, then it should be deployed into Production as soon as possible. On the other hand, it also gives us the flexibility if the team wants to stick to a fixed release cycle, typically at the end of a sprint.
The environments are Release/QA and Release/UAT. The UAT package that is generated is also sent to Production.
The TDS Setup
The solution adheres to the Helix approach, which means there are multiple TDS projects. TdsGlobal.config is a fantastic way to ensure that all the TDS projects are setup exactly the same way for all common elements. This also includes references to Git Delta deploy and T4 Code Generation Templates so that there is only one set in the entire solution.
There is a separate TDS project that contains no Sitecore items. Its function is to just bundle all the other TDS projects. Details can be found on Hedgehog’s TDS Classic documentation section on Package Bundling. Follow the Hedgehog TDS Best Practise guide.
All TDS Projects also reference to Hedgehog TDS Nuget package, and TDS Git Delta Deploy Nuget package. The end of each scproj file should look as follows. Take note that all references to Hedgehog TDS should be before TDS Git Delta Deploy.
Developer Workstation Setup
Whilst TDS Classic provides a very nice Sync Window dialog in Visual Studio to sync items from TDS project back into a developer’s workstation Sitecore instance, this process can be quite cumbersome. The complexity of Helix, multiple teams, different developer skillsets (Front End Developer vs Back End Developer), a developer going on holiday and then resuming working on the code base, would require a much more easier way to sync the TDS items back into Sitecore.
First, a configuration profile is created to only build (not deploy) the TDS Bundle project, and nothing else. I have used the following batch file to build the TDS package, with an option to allow users to enter a Git Commit Hash ID to build a Git Delta package.
Hedgehog Package Installer is the tool that I am using to build the TDS package. The process will also invoke a site publish.
Some people may ask why I am not using Sitecore Package Deployer or Sitecore Ship. A synchronous process provides a better developer experience for this process, whereas Sitecore Package Deployer or Sitecore Ship provides a better experience in the Release pipeline instead.
Release/QA Environment
The Git Commit Hash ID needs to be retrieved automatically based on the previous successful release. The LastSuccessfulRunGitCommtId parameter can be overridden manually at build time and the automated checks to find the Git Commit Hash ID will not proceed.
In TeamCity and Octopus Deploy, the build and release is meant to be done together. If a release at Octopus Deploy has failed, then the build status in TeamCity will be deemed as fail. This is done so that the Git Commit Hash can be retrieved correctly from the last successful deploy.
The MSBuild properties that needs to be overridden during builds look like /property:LastDeploymentGitCommitID=%env.LastSuccessfulRunGitCommitId% /property:LastDeploymentGitTagName=
In Azure DevOps, the build pipelines and release pipeline definition has no relation, which makes it a little bit trickier to find the last successful Git Commit ID.
The MSBuild properties that needs to be overridden during the builds are /p:LastDeploymentGitCommitID=$(LastGitCommitId) /p:LastDeploymentGitTagName=
Release/UAT
When a production release is completed, the Release/UAT branch will merged back into master, and then tagged. As part of the merging process, the property LastDeploymentGitTagName in TdsGlobal.config also needs to be updated.
The MSBuild step for the UAT build will read the LastDeploymentGitTagName automatically. Many Release/UAT merges and UAT deployments may happen before a production release.
Conclusion
I hope this will sum up how I have setup a Sitecore solution with TDS to work nicely on developer workstations and CI / CD Pipeline.
