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

By

Easy Cross-Solution Code Generation with inheritance in TDS Classic 5.7

If you want to use Code Generation across multiple TDS projects, you likely need one project to ‘know’ about another. For instance, you will need TDS.MVC.Master to ‘know’ about TDS.MVC.Base, as TDS.MVC.Master has templates in it, that inherit from templates found in TDS.MVC.Base.

As an example, with the projects and templates:-

TDS.MVC.Base
– templates/Global/PageItem

TDS.MVC.Master
– templates/Features/Custom/SpecialCustomPageItem

You might want the code to look like:-

public partial interface IPageItem    // from the template in TDS.MVC.Base
{
  string Title { get; set; }
  string Description { get; set; }
}
 
public partial class SpecialCustomPageItem : IPageItem
{
  // properties for fields found on the PageItem template (found in TDS.MVC.Base)
  public string Title { get; set; }
  public string Description { get; set; }
 
  // Additional field on SpecialCustomPageItem template
  public string Text { get; set; }
}

To have the code generated above (which is somewhat similar to what we have as an example for the Glass T4 templates here), the inheriting project needs to ‘know’ about the base template fields, and therefore, the base project.
Read More

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