Sitecore’s Helix Guidelines: The Best Bits

Rachel Drake
By Rachel DrakeDeveloper
5 minutes to read

Last year, Sitecore introduced the Helix guidelines which aim to make development efficient, cheaper and faster. Alongside this, Sitecore developed the Habitat site as a working example of Helix. Here’s an overview of some of the best features.

Separation of concerns

Helix promotes a structured coding framework, made up of three layers. The main website sits in the project layer. For multi-tenant work, there may be several projects in this layer each with a common project.

This layer then has dependencies on the feature layer. There are multiple layers on this project which each focus on a specific site feature like navigation, search or account. This makes it simple for developers to find the feature if changes need to be made.

Feature projects never depend on one another. This helps to reduce coupling and time spent finding dependent code that needs changing.

Helix also encourages features projects to be defined from a business perspective. So rather than defined by technology, features are defined by its use within the site which helps improve communication within businesses.

Whittling it down even further, features then have dependencies on the foundation layer. This layer contains the most basic functionalities required throughout the site such as CSS, indexing and the Sitecore framework itself.

Test driven development

When browsing the Habitat site, it’s impossible to miss the ever-present Test projects. Almost every single project has a set of tests sitting alongside it. This is a great feature; it gives us confidence in the product because it means we’re unlikely to miss a dependency through constant testing.

In addition to unit tests, Habitat uses SpecFlow for acceptance tests for each business requirement. This means that not only developers but project managers and stakeholders can be confident that the code does the job.

Added flexibility

Habitat is set up so the solution can be fully built using just command-line tools, namely Gulp. Initially, I thought Gulp was a tool exclusively for front-end development (we use it to compile our CSS and JS) but Sitecore uses it for this and much more.

Amongst other things Gulp is used to build a project, publish it to the relevant site folder, ensure all serialised Sitecore items are present and correct, and much more. This not only simplifies the build process but allows front-end developers to use the editor of their choice so they aren’t limited to Visual Studio.

Bonus extras

I’ve mentioned it before but this is an important point. Many of the naming and grouping conventions are based on business terminology and product understanding as opposed to a developer-centric view. This should make it easier to know, for example, what is meant by a ‘feature pod’ as everyone in the business should refer to it by the same name.

I was also pleasantly surprised to see that Sitecore now has its own NuGet feed! The feed is full of useful information including how to set it up. It makes it much easier for developers to reference Sitecore libraries and configure settings in their code as files can be pulled directly from Sitecore.

All in all, the Helix guidelines are a fantastic way to help streamline the development process. By having a demonstrable working example, Habitat helps developers feel confident in the work they are producing and is a great way to explore new features.

comments powered by Disqus

Articles by Rachel Drake

I am a backend developer here at Enjoy Digital specialising in Sitecore.