Every now and again developers run into problems that have already been solved but we just don’t know it. Sitecore is a wonderful platform that is highly configurable. But that level of flexibility comes at a price; there are more than a few configuration files involved with Sitecore. Unfortunately the default Visual Studio Build process will only transform the web.config. That presents a challenge when you want to have custom configuration files – like a sitedefinition.config – that changes based on the environment.
Wouldn’t it be great if you could setup a “stage” or “production” environment that would let content authors “Preview” content on the Content Management (cm)server without being logged into Sitecore? For this topic let us assume that we have a simple environment with a CM server and single Content Delivery (cd) server both running Sitecore 8.
That means you need different settings in your connectionstrings.config, your sitedefinition.config and –if you set one up- your PreviewDatabase.config.
Wait… PreviewDatabase.config? yes remember we started talking about making the CM work as a “preview” site for unpublished content. Let’s discuss that setup for a moment. First your connectionstrings.config will need a new entry for a “Preview” database. You will also need to get an empty copy of a web database, restore it as a preview, configure security and make sure you can connect to it with the connection string. In the SiteDefintion.config set the “database” to preview instead of web. The “previewDatabase.config” file is where you would want to configure the indexing for the preview database.
Within sitecore you need to configure a new publishing target called “Preview”. set this new target to use the “Preview” database and configure it so it is allows content to be published that is not in a “final” workflow state.
At this point I like to setup an “auto-publish” action in the “awaiting approval” stage that uses “Preview”, related and deep. This will ensure items are in the preview database when the content authors submit the draft.
If you deployed as is to your CM and CD servers like this you might notice some issues. Like the web database isn’t used anywhere and the CD servers have a “preview” index.
This is where SlowCheetah comes into play. My short description of SlowCheetah is “it is the missing config file transformation system that the web.config was given and all other config files were denied.”
You can add SlowCheetah to your project with Nuget and it just works. Build servers are able to use it without any fuss –outside of getting Nuget package restores working (and that is a different topic entirely). Simply right click on the config file, select “Add transforms” and SlowCheetah will add files for each build configuration you have defined in Visual Studios Configuration Manager (Debug, Release… and if you add them stage and Prod)
Lets talk about the Configuration Manager. By default your project will likely have a Debug and Release build defined. If you define a configuration for “Stage” and “Production” SlowCheetah can help you manage per environment settings by transforming the configuration files –and Sitecore configuration patch file- based on the selected configuration or environment.
That doesn’t help with a preview database because you need a per server configuration in the same environment. Let’s face it, the stage CM and CD are both in the same environment. That environment is different from the Production but your production CM and CD servers are all in the same prod environment. If you have a reporting, aggregation or indexing servers you will quickly see that you need to transform configuration files per environment and per server.
But SlowCheetah also addresses this issue as well.
Let us talk about deployments for a moment. I like to use “Web One Click Publish” to deploy code to my test servers. Here is the fun part- when you setup “Web One Click Publish” for your “stage CM server” and your “stage CD server” you can use SlowCheetahs “Add Transform” option and it will add new transformation files specifically for each configured publish profile. This means you can now set a transformation up so the CM servers SiteDefinition.config file turns the sites database to a “preview” database instead of the web database while the CD servers still use the “web” database. You can also remove the preview databases index configuration from the CD servers “PreviewDatabase.config” and remove the preview databases connection string from connectionStrings.config.
When SlowCheetah transforms a configuration file during the build it looks for a a file that is named based on the environment and runs that transformation. Once that is finished it looks for a file that matches the publishing profile and runs it. In other words it runs two transformations on each config file.
The order of operation is
- It runs the transformation file that matches the selected “configuration manager setting” (Debug, Release, Stage, or Prod)
- It runs the transformation file that matches the selected “Publish Profile” (stage CM server or stage CD server)
SlowCheetah will manage the transformations for you. It takes some getting used to managing the transformations especially if you are adding and removing elements/attributes in configuration transforms and applying updates, adding or removing them in the publish profile transforms as well. Once you get the hang of it, it makes configuring pipelines, indexes, databases, and processors within Sitecore patch files a breeze even when you have a “CI”, “QA”, “Stage” and “Prod” environment with multiple servers.
Give it a try and happy coding.
P.S. SlowCheetah’s usefulness is not limited to Sitecore. In fact, it does not know anything about Sitecore. It just lets you transform any config file like you would a web.config.