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

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

By

Change to the source control strategy on Habitat TDS

The HabitatTDS fork of the original Habitat codebase has been around for a while, but with the recent updates, I’ve decided to change the strategy that was in place (in case anyone was wondering where to grab the code from).

Previously, the master branch on HabitatTDS was kept exactly in sync with the original repo’s master branch.
This was done by setting an upstream branch pointing back to the original repo, and merging each update across to the HabitatTDS master branch.
By looking at the master branches in each, anyone could tell how up-to-date the TDS repo was when compared to the original (and was great for me to know if/when I needed to do another merge across).

Then there was the TDS-latest branch, in which the master branch was merged into, and the removal-of-Unicorn/introduction-of-TDS was performed.
Typically this was fairly easy, with only some new .yml files to be deleted, and the matching .item files being created and pushed.

Therefore, the TDS-latest branch represented the same snapshot of Habitat, in TDS form, at the point at which the master branch had been updated.

The problem with this was that the default branch for any repo is the master branch….so often we would have people come to the repo page, clone it (bringing down the master branch) and not know what to do as they couldn’t see TDS anywhere.

But now

To combat the issue of people mistaking the master branch for where TDS exists, I’ve flipped the process around.

A new branch has been created called original-repo.
This represents what master used to be….a snapshot of the original repo’s master branch, at the time it was last merged across.

And now the master branch is what the old TDS-latest branch used to represent…. that same snapshot in original-repo, but in TDS form.

Now this will make it easier for people to find the TDS branch of Habitat, allowing them to work with the many features that come with TDS that can’t be found elsewhere.

By

Powerful ways you can save on Sitecore development time

Working on Sitecore? How much time are you actually wasting, instead of getting work done?
Maybe you’re a Slack-er.
Maybe you just think, ‘that’s how it is’ and you do things the hard, time-consuming way.
Or maybe you actually want something better…..

Anyone that knows me in the Sitecore community, knows my love for the tooling and processes of Sitecore development. Working at Hedgehog, it’s something we are constantly analyzing from our own projects, and something we are always trying to improve on. We aim to keep development costs down on projects by not cutting features, but by working better. This leads to happier clients, who get more bang for their buck when hiring a Sitecore development team.

So how do we do it?

Well, at Hedgehog, we not only do client work producing websites, but we also dedicate people to work on tools and modules that help improve things. Most of the time, these tools are born out of the frustrations that we’ve found with the paradigm, but also from the general murmurs from the community. Having hands-on experience with the problematic stuff in Sitecore development, we’re in a position to try and find ways to improve it. Sometimes this leads to shared source modules that we create, sometimes it’s examples of projects for people to see, and sometimes, with enough demand, it can result in full-scale, commercial products with 24/7 support and dedicated development teams.

TL;DR

  1. Use all the productivity features of TDS Classic
  2. Use Sitecore’s own tooling
  3. Use what others before you have already created
  4. Don’t wait for Sitecore’s lengthy app pool reload….use ZeroDeploy instead!
    Sitecore is Loading

Read More

By

True Delta Deploys with TDS Classic

TDS (now TDS Classic) 5.5 introduced a feature called ‘Delta Deploy’ where the deployment of your project, either in development (using the Sitecore Connector) or in update packages, had the ability to ‘skip’ items assuming that they’ve already been deployed.

By default, we needed to build this feature in a way that was agnostic of source control provider (Git, TFS, SVN), and agnostic of source control strategy (main-line dev, Git Flow, Github Flow etc)…but extensible, so that teams could develop their own logic for their own project.
Read More