Automating the removal of TDS Projects

As part of the recent work I’ve done on migrating from TDS to SCS I had some tidying up to do. I needed to remove the TDS projects from the solution and all the files and sub-folders, including the .item files.

We had around 66 TDS projects in the Solution so this wasn’t something I wanted to do manually as It would take a while and I’d likely missing something. I figured someone must have written a script to do this but I couldn’t find anything. So I created a PowerShell Script myself to do this.

Note 1: There is a dependency here on the dotnet cli. This was the most efficient and supported way of cleaning up the solution file and most developers will likely have this installed already.

Note 2: I setup SCS to create my serialized items in an folder called scs. This was so all the legacy TDS items could stay in the serialization folder instead to separate them. If you’ve not done this you may need to modify the script below for your needs to re-configure the SCS folder before using my script.

If you save the script to your machine from the Gist below it will look something like this:

Show me the Script Already

When you open the script you need to set the variables for your Solution path, Solution name and if projects, files, folders and parent folders should be removed.
Most of these should be set to $true but depending on your folder structure you might need to set $tidyUpParentFolders to $false:

After the script has run you will see an output showing what the script has removed, including project files, item files and folders:

One you’ve run it check the removed files look correct before checking in your changes to source control. Also ensure your solution still builds and there are no issues.

Hopefully this is useful for anyone else who makes the move to TDS from SCS.

For more on Migrating from TDS to SCS read: A Guide to Migrating from Sitecore TDS to SCS

Upgrading Sitecore Content Migrator & Scheduling Content Syncs

Back in February I wrote about using Sitecore Content Migrator to Sync Content to your Dev and Staging Environments from Production.

Since then Jeff Darchuk has released a number of versions and in 3.1 on-wards it now support  Scheduling Content Syncs :-). This is great as it means you will no longer have to do this manually – this can take a lot of time if you have a few Sites and environments to sync. If your not already using Content Migrator yet then you can just go ahead and install 3.2* from the VS Package Manager Console like so:

Install-Package SitecoreSidekickContentMigrator -Version 1.3.2

However if you have an older version installed (like me) you will need to upgrade first. I didn’t find the steps after upgrading very clear, so I’ve documented this for anyone else who needs to do this.

* Note: you can install 4.0 rc2 instead, this is pretty stable from my testing and is a lot faster from what Jeff has told me.

Upgrading Content Migrator

Thankfully upgrading isn’t too difficult. Go to the project where you have it installed and run this command in VS Package Manager Console:

Upgrade-Package SitecoreSidekickContentMigrator -Version 1.3.2

Once you have done this you need to follow these steps:

  1. Rename zSCSContentMigrator.Local.config.example to zSCSContentMigrator.Local.config. You can find this in the folder /App_Config/Include/Sidekick
  2. Open this file and update it to include an authentication secret of at least 32 characters. You can use something like site this to generate a random key: http://passwordsgenerator.net/
  3. Also update the raw:BuildRoot and raw:BuildServerList nodes to use the same ones from your old config (zSCSContentMigrator.config in the root of App_Config\Include\)
  4.  Now you no longer need it you can delete the old zSCSContentMigrator.config in root of App_Config\Include\
  5. Upgrade on all environments including the one where you pull content from. This is important or it will not work correctly.

Setting Up A Scheduled Content Sync

Now for the fun bit. You can now set up Sitecore Content Sync so that it runs automatically and syncs content for you on a Schedule.

There is an example of a schedule commented out in zSCSContentMigrator.config.

You can un-comment this but I prefer to create a new config file to define the schedule like so so I can set name it per environment. e.g something like:

zSCSContentMigratorScheduling.Dev.CA.config.

We can then enable and disable the files as needed and it is clear which is for which. This file essentially replicates what you see in the UI for SideKick Content Migrator like but in config form.

Within this file you need to set the following settings:

  1. interval – usually in hours. we’ve set this to run once a day.
  2. remote server – this is where you pull you content from. In our case this is Production.
  3.  id root – these are the ids of the items in Sitecore who you want to sync down. You can add multiple IDs here. We’ve included a number of Sites in ours and also some media gallery folders.
  4. database – this will generally be master
  5. bulk update – update the search index for items on import. you might want to leave this set to false to speed up the import.
  6. children – migrate the children of the item. generally you will want this set to true, unless you only want to sync one item.
  7. overwrite – overwrite any content that isn’t on the remote server. You may want this set to false on Staging servers and perhaps development so you don’t loose local content changes.
  8. event disabler – prevent all events running the run when installing, moving, deleting items. usually you will want this set to false unless you have some custom events you want to fire.
  9. pull parent – pulls down the parent item of an item also. usually you will want this set to true.
  10. mirror – ensures all local content is cleared down and the local environment matches up. You may want this set to false on Staging servers and perhaps development so you don’t loose test or dev content.

Here is an example of a completed config:

<?xml version=”1.0″?>
<configuration xmlns:patch=”http://www.sitecore.net/xmlconfig/”>
<sitecore>
<scheduling>
<!–pull all content down from Production to Dev–>
<agent description=”Sync Core Production Content to Dev” type=”ScsContentMigrator.ContentAgent, ScsContentMigrator” method=”Run” interval=”24:00:00″>
<param desc=”remote server”>https://prod.mysite.com</param>
<param desc=”id root”>{6d8cf7fd-1099-4ab4-94ee-1e7a3c0c879b
},{9a6d463d-6d41-464b-bec4-ba8000f38ee2}</param>
<param desc=”database”>master</param>
<param desc=”bulk update”>true</param>
<param desc=”children”>true</param>
<param desc=”overwrite”>true</param>
<param desc=”event disabler”>true</param>
<param desc=”pull parent”>true</param>
<param desc=”mirror”>false</param>
</agent>
</scheduling>
</sitecore>
</configuration>

Testing Content Sync Is Working

If you use version 3.2 you will find that it records a record a record of the sync being carried out in Sidekick.

If you use the release candidate 1 or 2 for 4.0 then you will see some records in the logs such as:

Starting Content Migration…

Also make sure that you don’t have IIS recycling during your agent interval (in our case 24hrs) or the agent and content sync will never run.

I will write some more about how to solve this problem and other ways of scheduling this in a future blog post.

I found some of this wasn’t clear so hopefully this is useful for others.

Lastly thanks to Jeff for helping me out on Slack with some of this and for updating the module based on my feedback.

 

Simple Sitecore Content Synchronisation with Sitecore Content Migrator

As a Sitecore developer you often find you need to keep Dev and Staging environments up-to-date with Production in order to aid in development and in support and maintenance – otherwise it is very hard to successfully develop and test new features or replicate an issue from Production locally.

This used to mean manually backing up and restoring databases or creating Sitecore Packages to pull content down. This process is a labour intensive and error prone as well as a pretty daunting task :-(.

Sitecore Content Migrator to the rescue

migratorThankfully Jeff Darchuk created Sitecore Content Migrator back in October to do just this for you.

Sitecore Content Migrator is a free tool for Sitecore Sidekick which allows you to quickly and easily sync content down from one environment to another. It’s pretty simple to install and setup and then can be used whenever you want to carry out a sync.

It uses the same underlying technology as Unicorn (Rainbow), is pretty rapid and gives you some nice updates on progress along with a preview feature – so you can check all the changes before you run the import for real.

Installing & Configuring Sitecore Content Migrator

  1. First you need to install Sidekick itself. You can do this with the Sidekick Sitecore Module using the Sitecore package installer (https://marketplace.sitecore.net/en/Modules/S/Sitecore_Sidekick.aspx) or instead use NuGet to install it like so from Vistual Studios Package Manager Console:

    Install-Package SitecoreSidekickCore -Version 1.0.0.

    Ensure you install this on all environments you wish to pull content from as well as the environments where you will use it. This is because the service used by the Content Migrator must also exist remotely.

  2. Once you have installed the module you should find it has also installed 4 new config patch files (zSCS.config, zSCS.Aduitlog.config, zSCS.ContentMigrator.config, zSCS.Editingcontext.config). The one you want to edit is zSCSContentMigrator.config.
    Alter the servers list to include the environments you want to pull content from, in our case Production and Staging:

    <servers hint=”raw:BuildServerList”>
    <server>https://production.yoursite.com</server>
    <server>https://staging.yoursite.com</server>
    </servers>

Time to Sync

  1. Go to an environment where you want to sync content to. Click on the Start button and open Sitecore Sidekick. Then click on ‘Content Migrator’:
    sidekick-dashboard
  2. Select the server to pull content from (e.g ‘production.yoursite.com’), then browse the content node and select the content you wish to sync.
  3. Then check any of the following options to sync all content down and update the local site:
    –  ‘Migrate all children of selected item’
    –  ‘Overwrite all existing content with new content from the server’
    –  ‘If parent doesn’t exist locally add that too’
    –  ‘Make local content tree mirror the remote content tree’ Note: Jeff confirmed to me on Slack that this maintains the existing Sitecore IDs. So this is great if you use Unicorn and don’t want to mess up Dev content IDs.
    –  ‘Run using the event disabler’
    –  ‘Run using the bulk update context’
    Further information on these options and what they do can be found here: Sitecore Content Migrator
    content-migrator-step0

  4. Click the ‘Preview’ button
  5. Check that everything looks ok
  6. Click the ‘execute this operation’ button.
  7. Monitor the import and check that it completes successfully – look under the ‘Currently Running Operations’ section.
  8. Publish the site
  9. Test the site works as expected in your environment
  10. Rejoice as not having had to do much

Suggested Improvements

  • It would be really good to support automated scheduled syncs either by setting this up in config or saving an migration config. – I’ve already suggested this to Jeff and he’s logged it as a feature request.
  • It would also be cool to be able to sync multiple root nodes, e.g content and media library items at once.

All in all this is a great tool for making content syncs a whole lot simpler and allowing you to concentrate on development instead of manually keeping your environments in sync.