Sean Holmesby

.NET and Sitecore Developer

By

GitDeltaDeploy: Version 3 Released

The GitDeltaDeploy NuGet package has just received an update which addresses a couple of things that I’ve been meaning to get to for a while.

Rename of the NuGet package
Compatibility with the new YML serialization format
– A fix to a known issue where the order of the ‘targets’ file was dependent on other .targets files in the project file
– Made ‘DeltaArtifactsFolder’ configurable, changing the default from ‘{project}/Report’ to ‘{project}/bin/Delta’
– The removal of redundant conditions and operations
– A demo solution setup for testing different deployment scenarios offline (using a local git repo data)

Teams can simply update their existing NuGet package, including the newly named package as the dependency. i.e You should then have the package starting with ‘SaintSkeeta.’ installed in your project.

Then you can clean up the old project (the one starting with ‘Hedgehog.’) and ensure there are no remnant files still hanging around (i.e no reference to the old package’s targets file).

 

 

By

GitDeltaDeploy: Version 3 – Package, Project and DLL Rename

Highlighting that GitDeltaDeploy is a Third Party Extension
As a Hedgehog (and now Sitecore) employee, I found that a number of support requests for this open-source extension were being sent to the corporate support teams at Hedgehog or Sitecore, instead of the public Git repo. I can understand why people would send support requests to Hedgehog given this is an extension of Sitecore TDS (a paid product), and from my own personal involvement with the Hedgehog and Sitecore companies.
However GitDeltaDeploy is a passion project of mine, which I work on in my own personal time. It is also open-source…not owned by Hedgehog or Sitecore… and therefore, not supported by the official TDS Support or Sitecore Support teams.

As a result, I have decided to rename the project, removing ‘Hedgehog’ from the name, and instead replacing it with ‘SaintSkeeta’ (my Github username).

Read More

By

GitDeltaDeploy: Version 3 – Configurable DeltaArtifactsFolder

In GitDeltaDeploy version 3, I wanted to make the ‘output’ folder of the extension configurable.
This output folder is where the files ‘ChangedItemFiles.txt’, ‘LastDeploymentGitCommitId.txt’ are saved. Same too with ‘DeltaDeployCompare.txt’ when debugging.

In previous versions, this was declared in the .targets file in multiple locations with a hard-coded ‘$(MSBuildProjectDirectory)/Report‘ in 23 different locations.

GitDeltaDeploy v3 now has ‘DeltaArtifactsFolder’ declared at the beginning of the targets file.
By default this has been set to {project}/bin/Delta, which is a change from {project}/Report’ that it was in v2.

However the DeltaArtifactsFolder property is configurable.
Developers can configure a <DeltaArtifactsFolder> in their TdsGlobal.config file with the path they wish to use, or by passing it into the build command with /p:DeltaArtifactsFolder=PATH_TO_FOLDER

By

GitDeltaDeploy: Version 3 – Support for YAML Serialization

Version 3 of GitDeltaDeploy includes support for YAML serialization, which was added in TDS v6 to support the feature in Sitecore 9.2.

This feature was fairly simple to implement in the extension, by simply switching the file extension that’s used in the git diff command.

git diff -r –name-only –no-commit-id $(PrevIdentifier)..$(GitCurrentCommitID) “*.item;”
git diff -r –name-only –no-commit-id $(PrevIdentifier)..$(GitCurrentCommitID) “*.yml;”
Because either file format can be used in Sitecore and TDS, both are supported in this extension.
The GitDeltaDeploy targets file checks the $(SerializationFormat) property to determine which file extension to use. This property comes from the TDS project where you specify which option to use for serialization, so no additional parameter needs to be passed into the build for GitDeltaDeploy to work.
Note: When you first switch to YAML, all .yml files will be seen to be ‘new’…. so the first deployment will be a full deployment. After that, consecutive deployments will properly become delta deployments.

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.

Read More

By

Debugging GitDeltaDeploy with a Sitecore TDS project

As an open-source project, I wanted to enable developers to easily debug the GitDeltaDeploy extension themselves, in case of any issues or surprise edge cases they come across.

As GitDeltaDeploy is an open-source project, developers are free to download the Github repo and directly debug and edit as they wish.
It is a third party extension that I maintain in my spare time, so it isn’t affiliated with Hedgehog or Sitecore, and their support teams should not be contacted for help with this.
Instead I encourage developers to follow the debugging steps mentioned here, and to discuss their projects on the #tds channel in the Sitecore Community Slack.

Out of the box, the extension will create files that it uses for auditing whether or not items should be added to the deployment.
It does this by creating a ‘ChangedItemFiles.txt‘ file in a ‘DeltaArtifactsFolder‘ location (which is set as {project}/Report/ChangedItemFiles.txt by default), then by saving a ‘LastDeploymentGitCommitId.txt’ file in the same location for future delta deployments.

Read More

By

Configuring the MergeToolChooser application

I previously wrote about the MergeToolChooser application that lets you select different merge tools for different file types. Setting Git up to use it is defined in that blog post (you point your .gitconfig’s [merge] properties to the tool, and go from there), but I wanted to run through how to configure the MergeToolChooser application itself. (Official documentation is here)

The MergeToolChooser.exe is found in
C:\Program Files (x86)\Hedgehog Development\Team Development for Sitecore (VS2017)
(or the folder of your latest Visual Studio version’s TDS Classic install)

And alongside it is a config file that configures the merge tool designation.
C:\Program Files (x86)\Hedgehog Development\Team Development for Sitecore (VS2017)\MergeToolChooserConfig.xml

By default, there are only two Merge Tools listed in there….the Sitecore Item Merge Tool, and KDiff3, but I have a couple more examples you could use in my Gist.

Now, when git calls the tool, it can pass a number of parameters to it by using what you define in the .gitconfig.
Read More

By

The MergeToolChooser Application: allowing alternative merge tools for different file types

The MergeToolChooser application was included with the installation of TDS Classic version 5.1 to assist in the setup of the Sitecore Item Merge Tool.
The application allows you to select alternative merge tools for different file types, meaning you can select one tool for .xml files, another tool for .cs files, and another for json files if you wanted to.

This is particularly useful when using a source control provider like Git which only allows for one merge tool by default. In this case, you would point Git’s Merge Tool to the MergeToolChooser application, then allow the MergeToolChooser to designate which merge tool should be used for the given file type.

The MergeToolChooser.exe can be found in
C:\Program Files (x86)\Hedgehog Development\Team Development for Sitecore (VS2017)
(or the folder of your latest Visual Studio version’s TDS Classic install)
Read More