Hedgehog Team Development for Sitecore (TDS) v5.8 Review
Introduction
Hedgehog Team Development for Sitecore v5.8 was released back in March 2019. In this blog post, I will walk through the features that allows our Sitecore development teams in Isobar Australia to fully take advantage of, and some of the changes that have been made compared to earlier versions, which I previously blogged in “Yet another Hedgehog Team Development for Sitecore setup, from Developer Workstation to CI / CD Pipeline”.
WebDeploy Package
The major feature of TDS 5.8 is that it generates a WebDeploy package, which allows you to use MSDeploy to a Sitecore instance. It is very fast when compare to the old Sitecore Update package installation. TDS flattens all the serialised items in a flat folder structure. The installation service first disables item events and indexing events, then processes every single serialised files, and if Lightning Mode is enabled, compares the Revision ID to Sitecore, and then determines whether the serialised item should be deserialised into Sitecore.
A quick run through comparison with the old Sitecore Update package vs WebDeploy shows some significant performance gain. I had a client solution, when deployed an update package in full without using Git Delta, would take 90 minutes on my local PC. WebDeploy package took 5 minutes deploying in full.
Changes to our TDS setup
Due to the massive performance gain, the generation of Update package and Git Delta is no longer required. This also means Recursive Deploy Action can be used again to delete items for sections of a tree, and the TDS projects will be the source of truth.
However, deleting items automatically during a TDS Deployment can be dangerous, if the settings of the items have not been reviewed correctly. The key settings are “Child Item Synchronization”, “Deploy Always Field”, “Exclude Items From” and “Item Deployment”. There are some really great features from TDS to help validate the settings have been applied correctly for the settings above with the help of Validators.
https://www.hhogdev.com/help/tds/propvalidation
Package Install Post Processor
There are 3 actions provided by TDS after the Sitecore items are installed. They are “Trigger Save Event”, “Update Link Database” and “Publish after Deploy”. I personally find “Trigger Save Event” and “Publish after Deploy” are essential to every single Sitecore solution.
The “Trigger Save Event” acts as if the Save button has been clicked in Content Editor for every Sitecore items that are deployed. You can take a look in /sitecore/admin/showconfig.aspx to see the numerous amount of event handlers that are being processed when an “item:saved” event is raised. One important one is the Link Database is updated, which is the reason why I opt not to use the “Update Link Database” behaviour from TDS.
“Publish after Deploy” is as straightforward as it states. The processor utilises Sitecore’s Publishing Manager, which means this action works on both normal Sitecore Publishing, as well as Sitecore Publishing Service if it is installed.
Auto Sync
This is a very powerful feature, which can remove manually syncing Sitecore items into your Sitecore project, if the “Child Item Synchronization” setting is set correctly, and the solution adheres to modular Helix principles. I find this the most useful for Templates and Layouts. I have tested this out by modifying different modules directly in Sitecore, and have noticed the changes were automatically synced into the Visual Studio solution across various TDS projects in Foundation / Feature / Projects layer.
To utilise this, ensure the History Engine is turned on, which I have blogged about before.
https://medium.com/@Vincent_Lui/sitecore-9-x-history-table-and-history-engine-101f39488391
Hedgehog has a wonderful blog post describing the history of Auto Sync, it is definitely worth spending 15 minutes to go through it in detail.
Performance Bottlenecks
When working on our local developer PC’s, we have noticed that the TDS web deploy steps is still taking a little bit longer than we would like. The WDP packages, even when set up to only package Items only, still copies the 2 DLLs “HedgehogDevelopment.SitecoreProject.WebDeployClient.dll” and “HedgehogDevelopment.SitecoreProject.PackageInstallPostProcessor.dll” to the web site. That means the application pool recycles, which puts a few minutes of delay. Multiply that by 5 to 10 times a day, it can be quite disruptive to developers.
To tackle this problem, I am modifying the HedgehogDevelopment.TDS.targets file, and also introducing a new MSBuild parameters “SkipHedgehogDLLs”.
The provided PublishWebDeploy.ps1 Powershell Script has an option to not remove the TDS WDP Web Client API DLL — $remove.
Yeoman Generator for TDS Projects
I am sure most Sitecore solutions out there uses the amazing Yeoman Generator to help scaffold Sitecore Helix projects. The best TDS Yeoman generator I have seen so far is from the amazing Anastasiya Flynn.
She has added an amazing TDS Validator to be part of the Yeoman Generator template.
I would highly recommend everyone to modify their Yeoman generator to include the validator. Also adding your own validation rule that applies to the client project.
I am not going to attach my solution, as each Sitecore team has their own flavour / version of the Yeoman Helix Generator. It is easy enough to look at how other people in Sitecore community setups their generator and add the validator in.
Performance Optimisation Feedback
The Out Of The Box PostDeploy actions provided by Hedgehog can do with some performance improvements. Trigger Save Event, Publish After Deploy, Update Link Database Post Deploy actions all take the entire TDS_WebDeployItems.xml and fire off the events for all items as stated in the XML File, regardless of whether the items were deployed. This can lead to unnecessarily lengthy TDS deployments.
In HedgehogDevelopment.SitecoreProject.WebDeployClient.Jobs.SitecoreItemInstaller, the private method ProcessItemToDeploy reports the status of a Sitecore item deployment for each item to the console. I believe there is an easy way to then create a List, and update TDS_WebDeployItems.xml on the deployment status, so that the Post Deploy actions only fires off actions to applicable deployed items only.
Conclusion
The advanced features described above in TDS should help any Sitecore projects to streamline setting up TDS projects adhering to Helix Principles. The small modifications should also speed up TDS deployments so that TDS Deploy should now be less TeDiouS.
Please leave a comment if you like, or would like to comment / discuss what I have written in this blog post on anything TDS related.
