03Apr, 2020
Reduce Risk and Effort Configuring Sitecore by Using Role Definitions
Sitecore 9 has brought us a lot of new features, but the one I am most excited to use is role-based configurations. Non-developers beware; this will be a pretty boring subject matter for you, but you Managers might want to know this feature reduces solution and deployment complexity, which in turn reduces risk and increases efficiency.
If you've set up scaled Sitecore environments you're well aware of ye-old Excel sheet which has a list of configs to enable and disable, based on the instance's Role. I've spent a good chunk of time going over this file since I usually manage setting up these environments, and we will only have the time allotment to do this once. What's worse is I had once found out someone had gone in and played with some of the files post-installation, and the safest thing to do is review them all over again.
Now with Sitecore 9 all we need to do is define the server's Role in the web.config file, and like Mr. Sanchez says, “Awayyyy we go”! Your standard options are ContentDelivery, ContentManagement, Processing, Reporting, Standalone with the last one being default. Here's a peek for what it looks like:
<add key="role:define" value="Standalone" />
Role definitions can also be combined so you can switch from a standard Standalone instance to one that has “ContentManagement, Reporting, Processing” in preparation for adding a dedicated “ContentDelivery” one.
Further to the standard roles listed here, you can also add new ones to suit your needs like defining the environment which will come into play in the next section. Some examples of what we use are environment-specific options like Development, QA, UAT and Production.
Role-Based Configurations
So far, we've covered saving a lot of time with setting up scaled environments. Now let's talk about configuration files and how they're affected by all of this. Spoiler alert, it's pretty good.
We used to use configuration transforms which would modify the Sitecore config files based on the solution's build configuration. This worked for some of the specifics in play, but it wouldn't apply to a specific role in an environment. So, if we had a build configuration for UAT, the package being built would have configs to be applied to all instances there. The limitation of not having role-specific configs in UAT mean having files made as .disabled, and post-deployment steps of enabling them, etc. Thankfully this is no longer needed and what's more important is we can drop in all the solutions config files in every instance of every environment, having the “role:require” attribute everything for us.
This new “role:require” attribute can be added to configuration file nodes which will define which instance uses what. An excellent example of this is a scheduled task that must run in one instance only like Processing. Now though that Role is out-of-the-box we can also have role:require for the task set to “Processing and Production”, so it will only run on Processing in Production. You can also define a more frequent task occurrences for Developers by adding another for “Development”. You get the idea. Some more examples of these combinations are:
- role:require="Development or ContentDelivery”
- role:require="(Development) or (QA and Processing)”
- role:require="!Production” <- Notice !, which would apply to any instance not in Production.