Sean Holmesby

.NET and Sitecore Developer

By

GitDeltaDeploy: Installation and Usage Considerations

To use GitDeltaDeploy and have proper delta deployments working, there are some considerations.

This includes thoughts on: –

  • how developers work efficiently
  • what infrastructure you use for deployments
  • and how deployments are scheduled.

Here are some things to think about with your team when setting up GitDeltaDeploy.

Local Development or Deployments using the TDS-Sitecore Connector

Developers won’t really need GitDeltaDeploy for their local development…. it’s really only needed for package deployments, which we typically see done with non-dev environments.
This is because developers should be using a ‘Debug’ configuration locally, where the TDS-Sitecore Connector is being installed into their local website.
With this Sitecore Connector, TDS can directly communicate with the Sitecore instance, and therefore developers can benefit from ‘Lightning Mode‘.
Then for local (or ‘connector’) deployments, the Lightning Deploy Mode feature can be used to skip items that have unchanged Revision IDs.

The there’s little/no point in adding GitDeltaDeploy on top of that, as your deployment is already skipping the unnecessary items.

Package Deployment

Typically teams have deployments to non-dev environments (QA, UAT, Staging, Production) done with packages, usually on a ‘Release’ configuration.
When packages are created, there is no explicit link to the website, and no TDS-Sitecore connector installed. Therefore, there is no way to use Lightning Mode (with no way compare against the database item revision IDs at build-time).

This is perfect case for a delta deployment, and typically when GitDeltaDeploy can be used.

When installing into a solution with multiple bundled TDS projects, you only need to install the GitDeltaDeploy NuGet package into the bundling project (i.e the one that generates the bundled package).
Then turn on GitDeltaDeploy just for the package configuration (usually ‘Release’).

The GitDeltaDeploy DLL needs to exist alongside it’s Executing DLLs

As part of how MSBuild runs, the GitDeltaDeploy DLL is required to exist alongside the executing TDS ‘Tasks’ DLL.
If a project is using the TDS build components NuGet package, there is a pre-build step to automatically copy the GitDeltaDeploy DLL to that package’s folder (but beware, this might not be enough! See below).

OnPrem Build Server vs Cloud Build Server

When using an OnPrem Build Server, it’s likely that TDS was installed on the machine. If it has, the TDS Build components will have been installed to ‘C:\Program Files (x86)\MSBuild\HedgehogDevelopment\SitecoreProject\v9.0‘.
During a build, if this folder exists, it will be the location that TDS will execute from (even if the NuGet package is also installed by the project).
So if this is the case, then you will also need to copy the GitDeltaDeploy DLL to that folder on the machine so it can properly execute in your build.

For Cloud Builds (like Azure DevOps), TDS isn’t installed to the machine. Instead it runs entirely off the packages/HedgehogDevelopment.TDS.x.x.x.x files.
For this case, the automatic pre-build step in GitDeltaDeploy will copy the DLL over….and nothing else is required.

Using GitDeltaDeploy locally (or when an OnPrem TDS install exists)

As for ‘OnPrem’ builds above, it’s likely that developers will have TDS installed on their machines, and the ‘C:\Program Files (x86)\MSBuild\HedgehogDevelopment\SitecoreProject\v9.0‘ folder will exist.
To get GitDeltaDeploy working, developers will need to c
opy the GitDeltaDeploy DLL to that folder.
Another trick that can be used is to uncomment that folder’s .targets Import from your scproj files (but only if the NuGet package’s import is being used).

<!– Removed this one   <Import Project=”$(MSBuildExtensionsPath)\HedgehogDevelopment\SitecoreProject\v9.0\HedgehogDevelopment.SitecoreProject.targets” Condition=”Exists(‘$(MSBuildExtensionsPath)\HedgehogDevelopment\SitecoreProject\v9.0\HedgehogDevelopment.SitecoreProject.targets’)” /> –>
<!– Using this one –>
<Import Project=”..\packages\HedgehogDevelopment.TDS.6.0.0.13\build\HedgehogDevelopment.TDS.targets” Condition=”Exists(‘..\packages\HedgehogDevelopment.TDS.6.0.0.13\build\HedgehogDevelopment.TDS.targets’)” />

Storing the last point of your Deployment

By default, GitDeltaDeploy creates a LastDeploymentGitCommitId.txt file. This is for the next delta deploy to use as the starting point for the next delta deployment.
However some builds essentially do a ‘clean’ build….meaning the next deployment won’t have this file still around from the last build….it’ll be an entirely new folder.
Therefore, you may need to find a way to store this value in your build/deployment system, so it can be read for subsequent builds.

Planning Deployments Across your Environments

Now consider the ‘delta’ that is being produced by your build and if you were deploying that one package across your CI/CD stream, through QA, UAT, Staging and then Production.

Consider this case:-
Deployment A is pushed to production.
Deployment B is started, with the delta package created from when Deployment A was created.
Deployment B makes it to Staging but is canceled.
Deployment C is created.

Then the Deployment C package needs to contain everything since the Deployment A package was created, as Deployment A was the last successful deployment to Production.
For this, you would need to store a ‘LastDeploymentGitCommidId’ or ‘tag’ of when Deployment A was created in your build/deploy system.

One possible way to do this with Git has been described by John Rappel. Similar property setting can be done in Azure DevOps, or whatever your system is.

 

Something wrong with the delta build?

Remember you can debug your build by looking at the text files, logs, and even the MSBuild Structured Log Viewer tool.
You can try out these debugging tips, and discuss you findings on the #tds channel in the Sitecore Community Slack.

Leave a Reply

Your email address will not be published. Required fields are marked *