With Sitecore 9, Sitecore has redesigned the way configuration files are loaded and managed.
In Sitecore 9, the first thing we will notice post setup is that the App_Config\Include folder has no configuration files. Instead there's a new file in the App_Config folder called Layers.config.
Below is a snap from the file -
<layers>
<layer name="Sitecore" includeFolder="/App_Config/Sitecore/">
<loadOrder>
<add path="CMS.Core" type="Folder" />
<add path="AntiCSRFModule" type="Folder" />
...
...
<add path="PathAnalyzer" type="Folder" />
</loadOrder>
</layer>
<layer name="Modules" includeFolder="/App_Config/Modules/" />
<layer name="Custom" includeFolder="/App_Config/Include/" />
<layer name="Environment" includeFolder="/App_Config/Environment/" />
</layers>
From the above snippet it becomes rather clear that Sitecore is creating a layered structure for the different configuration files, and also these layers are loaded in a specific order.
To begin with Sitecore loads all of the "Core" configurations first, and all these are maintained in a separate folder. Next, any third-party modules will be loaded in the "Modules" layer. Thereafter, any custom configuration would be loaded from the current empty "Include" folder as part of the "Custom" layer. And lastly, any environment specific configuration gets loaded as part of the "Environment" layer.
This approach makes it much easier to keep all the different out of the box Sitecore configuration files separate from the custom configurations. Also, since each configuration layer has a specific folder for it, this makes tracking any update easier, as well as also helps in maintainability and troubleshooting the different layers.
In addition to the above mentioned layered approach, Sitecore has also introduced the concept of role-based configuration.
Note - This also marks the end of the era of creating folders with a prefix of "z" :-P
Role Base Configuration:
Role-based configuration allows us to assign any specific server role to an individual configuration node. For example, we can define some configuration settings specifically for say a Content Management, Content Delivery or a Processing server without having to go through the erroneous and painful steps of enabling or disabling the various configuration files on each of these specific servers. Further, we can also define your own custom configuration roles and assign the configuration information to those roles. This role-based approach provides a lot of flexibility, while also allowing for consistent, repeatable and automated deployments.
Sitecore has also provided a new admin page (/sitecore/admin/showconfiglayers.aspx) that allows us to view all the defined configuration layers, config files included with each layer, the different configuration roles that has been defined, and allows us to define new roles. It also provides us with the ability to select a specific role and preview the resulting configuration that would be generated for that type of server role. This allows us to essentially validate any environment-specific configuration in a single development environment without having to actually deploy our configuration to another server.
In Sitecore 9, the first thing we will notice post setup is that the App_Config\Include folder has no configuration files. Instead there's a new file in the App_Config folder called Layers.config.
Below is a snap from the file -
<layers>
<layer name="Sitecore" includeFolder="/App_Config/Sitecore/">
<loadOrder>
<add path="CMS.Core" type="Folder" />
<add path="AntiCSRFModule" type="Folder" />
...
...
<add path="PathAnalyzer" type="Folder" />
</loadOrder>
</layer>
<layer name="Modules" includeFolder="/App_Config/Modules/" />
<layer name="Custom" includeFolder="/App_Config/Include/" />
<layer name="Environment" includeFolder="/App_Config/Environment/" />
</layers>
From the above snippet it becomes rather clear that Sitecore is creating a layered structure for the different configuration files, and also these layers are loaded in a specific order.
To begin with Sitecore loads all of the "Core" configurations first, and all these are maintained in a separate folder. Next, any third-party modules will be loaded in the "Modules" layer. Thereafter, any custom configuration would be loaded from the current empty "Include" folder as part of the "Custom" layer. And lastly, any environment specific configuration gets loaded as part of the "Environment" layer.
This approach makes it much easier to keep all the different out of the box Sitecore configuration files separate from the custom configurations. Also, since each configuration layer has a specific folder for it, this makes tracking any update easier, as well as also helps in maintainability and troubleshooting the different layers.
In addition to the above mentioned layered approach, Sitecore has also introduced the concept of role-based configuration.
Note - This also marks the end of the era of creating folders with a prefix of "z" :-P
Role Base Configuration:
Role-based configuration allows us to assign any specific server role to an individual configuration node. For example, we can define some configuration settings specifically for say a Content Management, Content Delivery or a Processing server without having to go through the erroneous and painful steps of enabling or disabling the various configuration files on each of these specific servers. Further, we can also define your own custom configuration roles and assign the configuration information to those roles. This role-based approach provides a lot of flexibility, while also allowing for consistent, repeatable and automated deployments.
Sitecore has also provided a new admin page (/sitecore/admin/showconfiglayers.aspx) that allows us to view all the defined configuration layers, config files included with each layer, the different configuration roles that has been defined, and allows us to define new roles. It also provides us with the ability to select a specific role and preview the resulting configuration that would be generated for that type of server role. This allows us to essentially validate any environment-specific configuration in a single development environment without having to actually deploy our configuration to another server.
No comments:
Post a Comment