Fully Automating Git Delta Deploys in Sitecore

The holy grail of Git Delta Deploys is to make the process fully automated- meaning once it’s configured, TDS items are automatically culled from update packages or when using the connector, without any manual intervention between builds/releases. As I have outlined before, enhancements were made to the existing Git Delta Deploy code base that make automation possible. When leveraged properly, these updates provide a baseline for fully automating delta deploys.

Why Use Delta Deploys?

Sean Holmesby came up with the idea of Git Delta Deploys after reviewing this post on Sitecore Stack Exchange. During the release process, TDS is leveraged to push item updates to various environments, via either the connector method or via Update Packages.  Without delta deploys, TDS packages grow to staggering sizes. It is rather common to hear developers on Sitecore Slack griping about their deployment times when they are installing 5,000+ items. It can take upwards of 30 minutes for packages of this size to install. Clearly, this is unacceptable. Git Delta Deploys addresses this problem by only deploying items that have changed between given commits.

Why Automate Delta Deploys?

At face value, Delta Deploys still require a bit of manual intervention: updating either the commit hash or tag name regularly. The following options are available for configuring the delta:

  • Delta based on previous commit hash
msbuild MySolution.sln /p:Configuration=MyConfiguration /p:Platform="Any CPU" /p:CustomGitDeltaDeploy=True /p:LastDeploymentGitCommitID=commithash0123456789
  • Delta based on Git Tag
msbuild MySolution.sln /p:Configuration=MyConfiguration /p:Platform="Any CPU" /p:CustomGitDeltaDeploy=True /p:LastDeploymentGitTagName=ProductionRelease

Both of the available methods require that someone with knowledge of Git Delta Deploy to update the hash or tag the proper commit after a release is successful. Neither of these scenarios is ideal and can be easily missed or worse- performed improperly.

Fully Automating Git Delta Deploys

Two of the enhancements made to True Delta Deploys are key to automating the process: Delta based on Tag and Passing Commit ID as a Build Artifact.

1. Pass Commit ID as Build Artifact

When Git Delta Deploy 2.0.0 is installed and enabled, the build process will automatically create a file Delta\LastDeploymentGitCommitId.txt. This file can be located in two possible locations:

      • <TDS Project Root>\bin\Delta\LastDeploymentGitCommitId.txt
        • When testing builds locally, this location is used
      • <Build Output Directory\Delta\LastDeploymentGitCommitId.txt
        • When running builds from a build server, this location is used

The file LastDeploymentGitCommitId.txt contains a single line- the commit hash of the current build.  Because this file is pushed to the Build Output Directory, it is promoted to all environments as a build artifact.

2. Tag Repo During Production Release

Regardless of the deployment process used: VSTS Deployment, Octopus Deploy, etc. There is always the ability to execute custom steps via PowerShell. Since the commit hash is included as a build artifact, we can execute a PowerShell script to tag the repo.

The following script will:

      1. Read the first line of the LastDeploymentGitCommitId.txt file
      2. Clone the repo
      3. Remove  the previous tag
      4. Tag the proper commit based on the LastDeploymentGitCommitId.txt
      5. Delete the repo

	[string]$Scheme = "https",
	[string]$TagName = "ProductionRelease"

if(!(Test-Path $Location))
	New-Item -ItemType Directory -Force -Path $Location
$ReleaseHash = Get-Content $DeltaFile -First 1

$cloneCommand = "$($Scheme)://$($Username):$($Password)@$($RepoUrl) '$($Location)'"

Invoke-Expression "git clone -q $($cloneCommand)"

Set-Location $($Location)

Invoke-Expression "git checkout -q $($ReleaseHash)"

Invoke-Expression "git tag -d $($TagName)"

Invoke-Expression "git tag -a $($TagName) -m 'Production Release'"

Invoke-Expression "git push -q -f origin $($TagName)"

Set-Location ..

Remove-Item -Recurse -Force $($Location)


An example execution is listed below:

.\TagRepo.ps1 -RepoUrl "myrepo.com/_git/myrepo" -Username "myusername" -Password "mypassword" -Location "C:\TempRepo\OnServer" -DeltaFile "C:\Local\Path\To\Delta\LastDeploymentGitCommitId.txt" -TagName "ProductionRelease"

Note: Git must be installed on the server where the PowerShell script is run.

3. Configure Delta Deploy to Use Tag Name

With the repository properly tagged on the commit hash of our production release, we can now configure the build process to key off this tag.

msbuild MySolution.sln /p:Configuration=MyConfiguration /p:LastDeploymentGitTagName=ProductionRelease /p:CustomGitDeltaDeploy=True

Automation Confirmed

With these steps in place, automation is fully implemented. The build server will key off the ProductionRelease tag and cull items appropriately. As the build is promoted to various environments, the commit hash is pushed along. Once it reaches it’s final destination, i.e. Production, the repository is then tagged.

Each build and release process is different, so take this post as an example implementation.  The most important lesson is that all of the parts are in place to automate your Git Delta Deployment process. If you have any questions or if anything isn’t crystal clear, you can reach me on Sitecore Slack, look for the user jraps.


One thought on “Fully Automating Git Delta Deploys in Sitecore

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.