January 13, 2016
In a previous post we covered the anatomy of a Sitecore deployment*, but now that we know what a deployment is, what tools can we use to make it happen?
Let’s start with a quick recap. A deployment in Sitecore can be composed of several assets:
- .NET code in the form of compiled assemblies, Razor views
- Static assets such as CSS, JavaScript, images
- Sitecore configuration files in the App_Config directory
- Sitecore content items, which may be templates, renderings or general content items targeted at the master, core or possibly another custom database
What this list does not cover is that the “what” in a deployment will vary by two factors: environment and Sitecore role. By environment we mean things like development, integration, quality assurance, pre-production and production. And role is the service the target Sitecore instance is providing – management, delivery, publishing, aggregation, reporting, etc.
In a large deployment this can create many – easily dozens – of variations in what might constitute a deployment. Luckily, there is an abundance of tools available in the Sitecore community to address this challenge. Coupled with some standard .Net development tools, there are plenty of options. Let’s start with a quick run-down of the Sitecore specific tools.
Sitecore Deployment Tools
Team Development for Sitecore (TDS) is a commercial product. An add-on for Visual Studio, it allows development teams to source control almost anything in a Sitecore database. Coupled with code generation and automated deployment capabilities TDS is a must consider.
Razl, also from the makers of TDS, facilitates comparison and synchronization of Sitecore databases.
Unicorn is an open source tool that solves many of the same item synchronization issues as TDS, but takes a much different approach by automatically serializing Sitecore items to disk. If TDS is not in your budget, definitely worth a look.
Courier compares two content trees (serialized to disk) and can generate update packages. Source on GitHub as well as some video links in the readme.
Sitecore Ship provides a means to install Sitecore packages via HTTP. It is often used in conjunction with Courier.
As you can see from the above list of tools there are plenty of ways to manage the Sitecore content items; however none of these tools alone solve the problem of the variable nature of what might be in a deployment package. Some of that variability might include:
- Environment specific settings such as service end points or user credentials that change between dev, QA, etc.
- Sitecore configuration of databases and/or indexes; particularly as it relates to hardening content delivery servers
- Sitecore instance name
You get the picture. This is where we need to go back to the broader set of tools available for Visual Studio and msbuild.
Visual Studio, MSBuild and SlowCheetah
Most large scale solutions we have seen at Nonlinear start by leveraging the build configurations of Visual Studio. At a minimum, there is a build configuration per environment and possibly per environment/per Sitecore role as well. This allows us to include or exclude files. This simple capability is key to Sitecore as the most variable part of a deployment – at least in our experience – is the contents of the App_Config/Include folder. In the following screen you can see one other common use of build configurations: supporting multiple Sitecore versions.
The downside to the build configuration approach is that many files or settings end up being duplicated across build configurations. To help reduce this, a great tool is SlowCheetah. SlowCheetah is a visual studio add-on that provides the ability to write transform directives for any XML file which of course includes Sitecore .config files.
In the following example you can see how SlowCheetah transforms have been applied to the Keystone.All.ConfigurationManager.config file to create adjustments for the content management (CM) and content delivery environments (CD). When a build is executed, SlowCheetah checks the current build configuration – for example CA – and applies the transform before publishing the configuration manager file.
Murphy’s Law
Sometimes things go wrong. Knowing how to undo a deployment is just as critical. This is where things in Sitecore get interesting. There are some tools like Sitecore Rocks Anti-Packages that can help, but you’ll need to assess if that is sufficient based on what you are attempting to do. A great overview of Anti-packages can be found on the Sitecore site.
If antipackages are not an option, then a good old fashioned backup of the file system and Sitecore databases is the way to go. In fact, you should do a backup even if you have another means to rollback.
