Sean Holmesby

.NET and Sitecore Developer

By

TDS AutoSync – one way is not the only way

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.

Why Auto Push to Sitecore?

The thought of retrieving items from source control and have them automatically pushed to Sitecore has been brought up before. In one case it was mentioned by Kam Figy in his post about Unicorn’s Transparent Sync.

Imagine a scenario where a development team is working with a feature-branch driven workflow, like GitHub Flow. In order to perform a code review when using Transparent Sync, you merely checkout the feature branch under review and your Sitecore is immediately configured with the items that the feature includes.

This sounds like a great idea… but after thinking about this further, I realized that most (if not all) feature branches would not only contain Sitecore item changes, but also have code modifications to go along with those items.
For instance, developers will create/modify templates, add layouts, renderings, system items, and possibly add some test content items with these changes on them.
So for most of these changes, there’s likely to be accompanying code that should also be pushed to your instance.

It’s a huge part of the reason we use Sitecore item serialization. We have our code and modified items together as one in source control. Our changes with code and data get pushed together, as this is how they’re coupled in our Sitecore application.

Just pushing the Sitecore items to your instance is only half of the story. Without also building and deploying the code changes, the site would either break, or you’d see poor results, not quite giving you a complete view of the feature branch.

If the branch ONLY had Sitecore item changes, then sure, that works…. but how often in development is that the case?
It sounds like it would only happen if someone was doing content entry….not making code changes…. so then, maybe that’s intended for a different environment…. not something we’d pull into source control.

But how could we enable an Auto Push if we wanted it?

In the case where you want to check out someone’s feature branch, you should probably push BOTH the code and the items to your Sitecore instance.

With TDS, this can be done by right clicking on the solution, and selecting ‘Deploy Solution’.
This will build the code, push the content files and DLLs to your site, and then deploy your Sitecore items there as well.

Now you will have a full view of what the developer’s feature branch actually looks like.
You have the full picture, not just half of it.

But how can I automate it?

Still wanting to Auto Push when you switch feature branch?
Easy!
For Git, you can create a git-hook, which will detect you changing branch, and call MSBuild on your solution from the command line.

#!/bin/sh
 
# Originally from https://gist.github.com/akfish/8435506
# https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks
 
# Helper
safeRunCommand() {
    typeset cmd="$*"
    typeset ret_code
 
    echo cmd=$cmd
    eval $cmd
    ret_code=$?
    if [ $ret_code != 0 ]; then
        printf "Error : [%d] when executing command: '$cmd'" $ret_code
        exit $ret_code
    fi
}
 
# Get Project root path (without tailing /)
ProjectRoot="$(git rev-parse --show-toplevel)"
 
# Path To MSBuild.exe
MSBuild="/c/Windows/Microsoft.NET/Framework/v4.0.30319/MSBuild.exe"
 
# Path To gulp on machine
# export gulp=`echo $APPDATA | sed -e 's/^C:/\/c/;s/\\\\/\//g;s/$/\\/npm\\/gulp\\.cmd/' `
# echo "Gulp path is $gulp"
 
exec < /dev/tty
 
while true; do
  read -p "Do you want to run a build and deploy? (Y/n) (default n): " yn
  if [ "$yn" = "" ]; then
    yn='n'
  fi
  case $yn in
      [Yy] )  
        if [ "$3" != "0" ]; then 
          safeRunCommand $MSBuild $ProjectRoot/MySolution.sln /p:Configuration=Debug                              
          #    safeRunCommand $gulp My-Custom-Gulp-Script
          echo "Completed Build and Deploy on Debug configuration."
        fi
        break;;
      [Nn] ) echo "Skipping build and deploy. Remember to run this yourself to push the changes to your local instance!"; exit;;
      * ) echo "Please answer y or n for yes or no.";;
  esac
done

This will do essentially the same thing as the ‘Deploy Solution’ option mentioned above, and means that the code and items will both be deployed automatically on branch switch.

Is there something I missed?

Let me know if you have scenarios where only syncing items and not building the code is done.
I haven’t come across it with my own team’s development processes….but every team is different, so please let me know if there’s something I may have missed.

One Response to TDS AutoSync – one way is not the only way

  1. Jan Bühler says:

    For me, autosync needs to be turned on because the automatic serialization avoids forgetting about items that aren’t serialized yet before switching branches, which helps a lot – the truth should be in the version control. Not having used the TDS autosync feature in the past (just enabled it after our conversation), I’ve been very annoyed with syncing and checking for potential conflicts in the TDS GUI: Conflict resolution should be done in the version control system – TDS lead me to rechecking for conflicts in TDS, which was even necessary without autosync. Autosync at least warns my that I might have forgotten to check in some items. But that’s likely complaining about fixed stuff, I’ll see how TDS autosync works for me.
    Having build+sync done automatically on a branch switch is much nicer than just having autosync though.

Leave a Reply

Your email address will not be published. Required fields are marked *