Razl History View Scenarios

This post has been migrated from www.experimentsincode.com, we apologise if some of the images or content is missing

In my last blog post we went through a quick tour of the new History View available in Razl, in this blog post I look at how we can make use of this feature.

What did it install?

At some point in time as a Sitecore developer you will install a Sitecore package from a third party, for example a module, and wonder what did it actually install. Well here the history view can come to the rescue. To see how this works I am going to install the Glass.Mapper.Sc.Razor package, first I need to check what the last entry is: My last entry was clearly a keyboard mash, lets install a package and see what changes are made to the Sitecore database. To refresh the top of the list we have to scroll down slightly and then back to the top and Razl will refresh: We can now see all the changes made by the package, we could now go into TDS and add these items to our source control (feel free to debate if items in modules should be added to source control).

What Did I Just Do?

We have all been working on a Sitecore solution, happily adding content, templates and layouts and then got distracted and not added those items to TDS. When we come to add the items to TDS we have to try and remember what we changed. Using the History View we can quickly see the changes we actually made and then go back into TDS and add or remove them in source control.

Deployment to Multiple Live Content Management Servers

Imagine the scenario where you are working on a large website that has many different content editors making constant updates to the site. The site has multiple Content Management Servers (CMS) and they have a shared master database. You now have to deploy an update to live but you want to minimise the amount of disruption caused to the content team. One way to approach this might be to take one of the CMS boxes out of load and point it at a backup of the current database. You deploy all your changes on the new machine but then you need to sync the content between the updated CMS box and the old CMS being used by the content team. At this point you have to manually package the changes made by the content team and then migrate them across to the new instance. If you have a large content team or the updated CMS has been out of load for a while there could be a lot of data to update. You also have to ensure that your content team have remembered every action they performed and that includes updates and deletes. Now imagine having to do this across 3 or 4 CMS machines over several days and this could be come a very tedious and error prone solution. This is where the history view in Razl helps and makes a slow painful process quick and easy. We just point Razl at our two databases and then we can quickly see the changes that were made and move them across: This makes a slow error prone process very quick and easy for the deployment team who can then be confident that they won’t miss any changes.

Summary

The new history feature is a great addition to the Razl tool and can really help speed up you work with Sitecore when you aren’t sure what changes have been made. Razl is a constantly evolving and improving product and if you have any suggestions we would love to hear them on the GetSatisfaction site.