Why We Switched From Sitecore Ship to Hedgehog TDS Sitecore Package Deployer
In one of our recent projects utilizing the newest version of Sitecore 8.2, we attempted to use our automated deploy system to launch the site for the first time using our usual deploy process which includes the use of Sitecore Ship to run our Sitecore TDS DB updates. We have used Sitecore Ship for previous projects successfully, but at this time of writing the deploy appears to be silently failing in that everything appears to run as expected, but the items never appear in our master or Core Sitecore tree. Here's what gets returned when we hit the update URL with a Core update file:
As you can see, it does appear to register that something is going on with items, even showing specific GUIDs, but then the items are nowhere to be found.
In Comes the The Sitecore Package Deployer (SPD)
We needed a quick solution, so we came across the SPD by Hedgehog and started using that immediately. The default functionality is that every minute it checks inside of a specific folder for .update or .zip files, consumes them, and spits out .json files with the update results. There are various benefits to this approach, as is explained on their blog post about it.
The only thing SPD seems to be missing in my eyes at this point is the option to automatically publish Sitecore items to the Web DB.
At this time of writing, no NuGet package exists so we installed this functionality by using the Sitecore Installation Wizard (
https://site.com/sitecore/admin/UpdateInstallationWizard.aspx) to upload the .update file that can be downloaded here.
This will install several files:
- Several bin related files, many of which we found to be unnecessary in the version we installed. We only used
Of course, the installed files must be persisted by adding them to your solution and source control appropriately so that they get deployed properly. This will vary from project to project.
One interesting conundrum we ran into was that since the default update file input folder is located in
Data/SitecorePackageDeployer, we must make sure that the directory exists. You may want / need to add it to source control, but empty directories cannot be stored in source control. Our solution involved placing a
.gitignore file in that directory with 3 lines that exclude any items or directories that get deposited into the folder, while making sure not to exclude itself:
* */ !.gitignore
When deploying, make sure that the folder actually gets created, otherwise you may have to manually create it, depending on your setup.
The whole deploy process actually sparked some internal debate about how we persist and deploy these files across various environments. One approach is to include bin and sitecore folder contents in source control, but that has drawbacks. Should you choose not to include these installed files in source control, one must find a reliable way to include the file installation as part of the development and deploy process. The goal of course should always be to strive for consistency across environments, and even if that means you are manually copying some files into different environments, as long as your process is ironclad and repeatable by someone other than you, then you minimize the risks.
We think Sitecore Ship is great and it has served us well. The switch to SPD was easy enough, so we took the opportunity and so far it appears to be working as expected. Thank you to the contributors of Sitecore Ship as well as Sitecore Package Deployer for the helpful software! If YOU the reader are able to contribute to these projects, please do!
All the best. - Marcel