Sean Holmesby

.NET and Sitecore Developer

Feb
28

By

GitDeltaDeploy: Version 3 Released

Category: Sitecore Tags: , , , , , 3 Comments

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).

 

 

Feb
28

By

GitDeltaDeploy: Version 3 – Package, Project and DLL Rename

Category: Sitecore Tags: , , , , , Leave a Comment

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

Feb
28

By

GitDeltaDeploy: Version 3 – Configurable DeltaArtifactsFolder

Category: Sitecore Tags: , , , , , Leave a Comment

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

Feb
28

By

GitDeltaDeploy: Version 3 – Support for YAML Serialization

Category: Sitecore Tags: , , , , , Leave a Comment

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.

Feb
28

By

GitDeltaDeploy: Installation and Usage Considerations

Category: Sitecore Tags: , , , , , Leave a Comment

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

Feb
22

By

Debugging GitDeltaDeploy with a Sitecore TDS project

Category: Sitecore Tags: , , , , 3 Comments

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

Mar
16

By

Configuring the MergeToolChooser application

Category: Sitecore Tags: , , , , 1 Comment

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

Mar
16

By

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

Category: Sitecore Tags: , , , , Leave a Comment

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

Jan
29

By

Change to the source control strategy on Habitat TDS

Category: Sitecore Tags: , , , Leave a Comment

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.

Nov
14

By

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

Category: Sitecore Tags: , , , Leave a Comment

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

« Older Posts