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

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

Apr
20

By

TDS AutoSync – one way is not the only way

Category: Sitecore Tags: , , , 1 Comment

This blog post was inspired by a comment on the TDS v5.5 Feature Spotlight Video for AutoSync.
The question was this:-

“Does it sync the other way around also? When you retrieve items from your source control and need to push them to Sitecore?”

The simple answer to that is no. AutoSync in it’s purest form only works one way. It will read changes from Sitecore into your TDS project, but will not take .item file modifications and auto update Sitecore with the changes.

We can make it happen though….. but first, the question has deeper connotations that I want to discuss.
Read More

Mar
16

By

TDS: The Evolution of Auto-Sync

Category: Sitecore Tags: , , , Leave a Comment

Team Development for Sitecore (TDS) version 5.5 has now been officially released to the public I’ve had a play with the impressive list of new additions, and loved the further improvements to my Sitecore development efficiency. Features like the new Delta Deploy feature, and the Auto Deployment of Content Files have me doing Sitecore development quicker than ever.

One big new addition available in TDS v5.5 is the AutoSync feature… Another efficiency helper, where Sitecore changes get synced back to the TDS project automatically.
It has been described as a ‘new’ feature…. But is it?

Really, Auto-Sync has existed in TDS for a while, it’s just taken on a new form in v5.5.
Let me explain what I mean by this.

Read More

« Older Posts