It’s something everyone’s had to do at some point. How can you best migrate content from your dev machine to other environments e.g. qa / uat / live etc.

Before we carry on let’s define exactly what we mean by content. I’m not talking about files here, let tools designed for deploying files handle that problem. By content I mean Sitecore items. These can be broken into two key areas:

• content owned by content editors
  • typically items under /sitecore/content and /sitecore/media library
• content owned by developers
  • typically items under /sitecore/layout, /sitecore/system and /sitecore/templates

In theory both can be migrated in exactly the same way – it’s out the box and is called packages. Via the desktop you can decide which items to package up and simply download a package file. The counterpart is you then install this package in other environments and you’ve migrated your content.

So, why a blog post on something you get for free?

A lot of the information here is based on experiences of migrating content between lots of environments, that’s been edited by lots of people in several different places. Trust me, packages work but can become somewhat cumbersome and error prone as you scale things up.

Some key factors it’s worth considering for the following discussion:

• How easy is it to build up your changeset?
• How quick is it to install these changes?
• How easy is it to see which versions of your changeset have been installed?
• What happens if you get a ‘merge’ conflict?
  • E.g. what happens if an item in your changeset has been updated in the destination environment
• How easily can your changeset be source-controlled?
• How easily can your changeset be updated / versioned?
• How easy is it to deploy your changeset to your publishing targets?
• Can the installation be clever?
  • E.g. could you add logic to the install process or even base content it installs on existing content

What options do you have?

Note, this list isn’t meant to be exhaustive so apologies if you think items are missing – it’s aim is to highlight answers to the list of questions above. Several tools solve these issues in similar ways. The pros and cons are based on field experience of using each.

Sitecore packages:

These are available to use in an out the box Sitecore installation. Creating packages can be based on cherry picking the items from a specific database you know have changed or basing on some dynamic rules (e.g. what’s changed recently).

Pros:

• They are out the box and quick to get started with
• You can open the output zip and peer in
• It’s possible to save an xml file which represents the full content of a package

Cons:

• Source controlling their content is tricky as they are output as a zip file
• It can be tricky to get clear visibility of which version of packages have been installed to specific environments
• Content still requires publishing if installed into master
• Keeping them up-to-date with changes, especially with a large team can be laborious
• Validating their content is slow
• Installing lots of packages in one go is a painful process
• Install options are somewhat unclear:
  • Overwrite can nuke existing content
  • Merge – does anyone really understand the 3 options?
• Field level updates aren’t possible

Sitecore update files:

Much like packages update files store a form of serialized content in zip files. There isn’t a way to generate update files out the box so I won’t dwell too much on this option. IMO they suffer many of the same issues as packages.

FYI TDS allows you to generate these files. 

Pros:

• Partial item updates can be achieved
• You get detailed installation history and (undocumented) rollback options in the /temp folder

Cons:

• You can’t simply generate this type of file

Unicorn / TDS:

Unicorn and TDS take a slightly different approach in that they store a view of the world in your solution. Both rely on serialization to generate a view of configurable areas of the tree, Unicorn diverting slightly by using a custom yaml format for its files.

Installing each is slightly different: Unicorn hosts a custom page that allows manual or automatic syncing of files, TDS allows you to generate update files.

I’d argue both these approaches suit developer content well, I’ve struggled storing large amounts of content editor content in both.

Pros:

• Source control is your view of the truth – items can be branched & merged along with your code
• The deployment process can be automated

Cons:

• TDS does come with an additional cost
• Deploying to all publishing targets requires the changeset to include content configured for each target
• In TDS building more complex installation rules is possible however difficult to visualize (note, I’ve not used the product for a couple years now, this may well be better)
  • Examples in mind would be: sync once, field level configuration

Scripting your changes:

You build up custom scripts / helper pages / ???? to allow changes to be made via the Sitecore api’s (or database if you are feeling particularly Chuck Norris). Let’s assume we have a means for scripting these changes via some some json configuration (see the summary :)).

Pros:

• If done right you get an easily re-playable process that can update content in any publishing target
• All the scripts are source-controlled
• Scripts can base decisions on existing content
• Scripts can be as granular or as course as you want – bulk updates on multiple items vs single field updates on specific items

Cons:

• Every change requires ‘scripting’
• A considerable shift in approach is required
• A raft of external tooling is required to facilitate generating and installing scripts

Summary, or should it be sales pitch?

We use the last approach across most dev teams here so would be used for countless deployments per day. For us it works and is infinitely re-playable. Think of it like advanced config transforms for your content.

I’ll write up more details on the specifics of sinj in a later post – to get started have a look at https://github.com/tcuk/sinj

I’m hoping the information above gets you thinking – just because certain tools exist doesn’t always guarantee they are the best for the job!