Complying with Sitecore Helix, Sitecore's design principles for ALM and DevOps.

In a previous post I highlighted some quick wins that everyone can take from Sitecore Helix ( In this article I wanted to take some time and dive a bit deeper into DevOps and ALM considerations and provide several pointed recommendations that we believe are potential gaps worth addressing.

Reminder: Sitecore Items are a part of your solution

Let’s start with a quick, but important reminder. No Sitecore solution is complete without the inclusion of your templates, renderings and other custom Sitecore items. As I have noted previously we use Team Development for Sitecore (TDS) to source control Sitecore items.

The relevant Helix documentation is

Development, Build, Testing, Deployment

Helix describes four application phases ( For the purpose of this blog, we will align to them:

  • Development - in which the features or modules are being built

  • Build - or Integration in which the implementation is put together as a single testable package

  • Testing - in which the features or integrated package are tested against the specifications

  • Deployment - in which the package is ultimately deployed onto the production environment

I think we can agree these are a reasonable starting point, but perhaps lacks some nuance. Simple example - a solution that is operational or has content you need to preserve will have different considerations than a greenfield situation where each deployment can rebuild a target environment. As it would be impossible to address all situations I think it reasonable Sitecore leaves these elements to the reader to address.

That said, there are some specific elements I do think are worth calling out and possibly changing.

1) Development

One omission in the Helix guidelines is the lack of mention of code generation. If developers are manually building code to abstract the data model of Sitecore they are missing out on one of the simplest ways to gain productivity and consistency across a development team.

As a standard practice our solutions use Team Development for Sitecore to generate classes and interfaces for data templates used in component sources and pages. The result is the automatic generation of models for MVC and more general purpose classes for data manipulation.

For more on TDS code generation see

That said, if you are stuck on hand coding ORM, go for it.


Perhaps this should go without saying (Helix does not call it out), but testing a Sitecore solution requires that the target environment mirrors what you will have in production. I frequently encounter organizations that attempt to “save” on non-production licensing and instead of testing code in an environment with scaled management, delivery, publishing etc., they attempt to test in an overly simplified view of the final environment. The chance of solution failure in production is much higher.

If your production environment has more than one Sitecore instance, then your testing environment needs it as well. I would consider a minimum testing environment to include a content management and a content delivery instance.

While we are on the topic of testing, that testing environment should also have the same or a very recent version of the production content.


Deployment guidelines in Helix are flexible and focus on defining ownership. I understand the challenge of addressing the wide variation in solutions, but there are some potential dangerous implications if the guidelines are taken at face value. I think the guidelines require a much finer point and need to be more prescriptive. Let’s start with what Helix says:

“Some data and configuration is owned by the development process (such as C# code, views and the template structure) while others are owned by the production environment (such as the content items). It is important that your deployment process takes this into consideration and maps this carefully. This is especially important for items in Sitecore and configuration in .config changes – both of which can be managed in multiple places. Also, this is important in an automation process, as you do not want to overwrite production content or configuration by accident or be unable to test on a representative production-like dataset.

The detailed ownership and direction of flow depends on the business logic and requirements of the solution. For example, although templates are most often managed in development and should at all times be deployed from development to production, in some rare cases Project layer templates, such as Page Type templates and Datasource templates, can be managed partly in production to allow for dynamic fields and content.”

Let me start with what I would consider the easy one. All .config changes should be managed in the solution and deployed. Allowing manual environment specific .config changes is a recipe for unreliable testing and suspect ability to rebuild an environment to spec. If your deployments are automated – of course they are – this should not be a burden.

The second paragraph, which allows for the idea of templates to be managed in production is in my humble opinion a totally irresponsible act. Template authoring has system wide implications. The moment that template is published it will affect the production site. If someone out there reading this has a use case that requires this I’d love to hear it, but again my default stance is that templates are part of the solution and deployed. 


The above content is an opinion based on my experience. I am sure there are those who disagree, but that is I think one of the best thing about Helix – Sitecore is very clear. It is a set of design principles and not rules or best practices.

I look forward to seeing Sitecore continue to evolve this valuable guidance. For those that need the reminder, lots more to read in the official Helix docs at

comments powered by Disqus