Recently we had a client who wanted to be able to preview content before they were publishing it live with Umbraco. Because we’d made some major modifications to the way the content was rendered we were unable to use the standard Umbraco preview since we weren’t using any of the <umbraco:item /> tags. So this posed a problem, how were we going to have the preview working?
We decided that we were going to have to have a content entry server, from here they could enter their content, publish it and view it, but how were we then to get it to the live site? The logical answer is that have a periodic push of the content entry servers database across to live, but that’s not ideal and it is a pretty nasty idea.
To add another level of complexity on top of the system the site has user generated content, this content would obviously be entered by site visitors and it would only be on the live site, not the staging site.
Hmm…
Then Shannon reminded me of a conversation which we had when we were in Denmark at CodeGarden 09, someone had suggested that you could use Red Gate’s SQL Data Compare to push the data across.
So I sat down with two copies of the database, and decided to work out what would be needed to achieve this. Essentially you need to reseed Umbraco so that when you do changes on one environment it can easily be spotted and resolved by Red Gate.
The following is the list of tables which you need to reseed:
- cmsContent
- cmsContentVersion
- cmsDocument
- cmsPropertyData
- umbracoNode
Microsoft SQL Management Studio will be able to generate reseed scripts for these tables which will handle the data migration and everything.
With this set up it opens an interesting idea which we plan to trial, having every environment seeded differently from dev onwards and using Red Gate to migrate from one to the next.
Things to keep in mind:
If it’s likely that there will be content created/ edited on both environments make sure that you put the primary key seed to be greatly spaced. For this site we reseeded the content entry environment with a start identity of 500,000. This left a good sized buffer in the cmsPropertyData table which is the table that expands the most.
If you wanted to be able to sync across multiple environments you could do:
- Dev – primary key index starting at 1
- Content Entry – primary key index starting at 500,000
- Live – primary key index starting at 1,000,000
If you want to sync more than just content (eg – Macros, Document Types, etc) you’ll have to reseed their appropriate tables too.
You still need to manually copy the Media folder across environments still, as those files aren’t stored in the database.