Sitecore Git Delta Deploy 2.0.0
September 12, 2017
At GeekHive, Team Development for Sitecore (TDS) Classic is an essential tool for every Sitecore project we work with. We know it well and understand how to leverage it to improve our quality and efficiency. An area that we have been focusing on lately is our DevOps process as it relates to promoting items. Steve VandenBush has written about this at length on several occasions. Our preference for item promotion is to use Update Packages over the standard TDS Connector method (due to: latency involved with this method, firewall issues between build server and CM servers). Update Packages allow us to push all items in one file (
*.update) to a remote server, and then run the installation directly on the remote server. This works fairly well for small projects, but with large projects (read thousands of items) even this method begins to crawl. These cumbersome installations are widely known by the Sitecore community; Sean Holmesby took it upon himself to come up with a solution and thus Git Delta Deploys (GDD) was born.
Conceptually, GDD deploys only changed
*.item files between two different Git revisions. It can be used via the Update Package method or the connector method. By only including items that have changed since a given revision, the overall size of the installation is drastically reduced and therefore release times are reduced. I began using it on a recent project and quickly realized the possibilities. Throughout my endeavor, I found a few bugs and areas for improvement. With the guidance of Sean, we were able to launch version 2.0.0.
Bug Fixes from 1.0.0
If you were using GDD before, you may have run into some recent bugs that have been addressed.
- Support for Update Packages
- Previously, only the connector method was supported.
- Proper Diff Sequence
- The order of the diff was incorrect leading to missed item files in the delta.
Support for Tags
Prior to these updates the only method for targeting a previous revision was via a commit hash, passed to the build as
LastDeploymentGitCommitID. Now, it is possible to target a previous revision with a Git
Tag. Now, if you tag a commit as “ProductionRelease“, each execution of
msbuild /p:CustomGitDeltaDeploy=True /p:LastDeploymentGitTagName=ProductionRelease will compare the current commit (
git rev-parse HEAD) with the commit associated with the “ProductionRelease“ tag and only deploy changes between them.
If your team uses the file deploy feature of TDS Classic, you can benefit from the ability to perform a delta of the code files. This can be accomplished using the optional parameter
msbuild /p:CustomGitDeltaDeploy=True /p:LastDeploymentGitTagName=ProductionRelease /p:CullProjectFiles=True). This task performs the following operations:
- Obtains a list of all files in the git repository
- Performs a diff between the current revision and the previous revision (either via commit hash or tag)
- Given first two operations, creates a file that includes the file path of all unchanged files, one per line
- Removes all unchanged files from the output directory using Step 3
The output of this operation is stored in the <ProjectDirectory>/Report directory.
The File Delta is not a true delta. Since the built files are not stored in source control it is unable to remove all files. It can be summed up with the following.
File Delta will deploy all…
- Items not in source control
- Project DLL’s
- Minified CSS
- Aggregated JS
- NuGet Packages
- Items in source control that have changed since a given revision
- Text files
- Referenced DLLs
- Config and XML files
- These are always deployed as there may be transformations applied that are undetectable, so the safe bet is to deploy them.
Pass Commit Hash as Build Artifact
Since builds and releases are often decoupled, it is sometimes impossible to determine which commit triggered a given release. While there are various ways of sending this data depending on the Continuous Integration (CI) method used, a fail safe was added. Now, GDD will create the following directory + file:
<OutputDir>\Delta\LastDeploymentGitCommitId.txt. This file contains the commit hash of the build that was used to generate the release. It can be useful for automation of GDD. For example, by knowing the commit hash that was used for a given release, API’s can be utilized to remotely re-tag a repository.
Note: Currently this file is not included in an update package that includes code files. It is available in the primary Output Directory of the build.
Real World Examples
The following examples are all given via MSBuild commands, however, as Sean Holmseby has explained in his post, they can be configured within the TDS
*.scproj files as well.
Only build items that have changed from a previous hash to the current hash
msbuild MySolution.sln /p:Configuration=MyConfiguration /p:Platform="Any CPU" /p:CustomGitDeltaDeploy=True /p:LastDeploymentGitCommitID=commithash0123456789
Only build items that have changed from a previous tag to the current hash
msbuild MySolution.sln /p:Configuration=MyConfiguration /p:Platform="Any CPU" /p:CustomGitDeltaDeploy=True /p:LastDeploymentGitTagName=MyTargetedTag
Only build items and files that have changed from a previous hash to the current hash
msbuild MySolution.sln /p:Configuration=MyConfiguration /p:Platform="Any CPU" /p:CustomGitDeltaDeploy=True /p:LastDeploymentGitCommitID=commithash0123456789 /p:CullProjectFiles=True
Only build items and files that have changed from a previous tag to the current hash
msbuild MySolution.sln /p:Configuration=MyConfiguration /p:Platform="Any CPU" /p:CustomGitDeltaDeploy=True /p:LastDeploymentGitTagName=MyTargetedTag /p:CullProjectFiles=True
The Future of GitDeltaDeploy
Keep an eye on the GDD GitHub repo for updates in the future.
Stay up to date with our email updates!
Never miss out on a Sitecore update again!
Our newsletter features a blog roundup of our top posts so you can stay up to date with industry trends, tutorials, and best practices.