Alternatives to Sitecore Habitat
I previously blogged about the main themes of the Helix principles, and how each of the main aspects of Habitat achieves the aims of Helix. Of course, Habitat is only one interpretation of Helix - but unfortunately it looks like copying Habitat has become a common way of implementing a Helix solution. Habitat is a coherent implementation of the Helix principles, but it is meant only as an example. In this post I take a look at way of changing one of the “dominant” aspects of Habitat to arrive at a different implementation approach.
How many Visual Studio projects?
In my view, the most drastic aspect of Habitat is the usage of one Visual Studio project for each Helix module, meaning that as your solution grows and evolves there is no upper bound on the total number of projects/assemblies. This may cause a number of problems, such as:
- Additional manual effort or tooling needed to create a new Helix module (although check out https://github.com/kamsar/generator-habitat/ and https://marketplace.visualstudio.com/items?itemName=AndersLaublaubplusco.SitecoreHelixVisualStudioTemplates as starting points for scaffolding Helix modules)
- Slower build time due to an increased number of Visual Studio projects
- The need to develop outside of the website root because your non-code artifacts (views, config, CSS, JS, etc) are scattered across multiple Visual Studio projects - this means the need to “publish” your website after building (although the Habitat example contains some useful Gulp trickery to help development workflow, and also check out https://github.com/richardszalay/helix-publishing-pipeline)
- The performance of Visual Studio itself may struggle with a large number of projects, depending on your development setup
Contrast the downsides against the upsides, and you might find you’re not getting a return on your investment in the VS project-per-module approach:
- The VS project-per-module approach also means your modules are separated on the filesystem (i.e. all module artifacts will end up inside a containing folder specific to that module.) Also module artifacts are clearly separated for the developer in the Visual Studio UI, as a consequence of the project structure. While this is an upside, as it helps enforce the conceptual module boundaries with “physical” boundaries, it needs to be balanced against the potential downsides
- The VS project-per-module approach allows the option of having different “views” on the overall implementation by creating extra Visual Studio solutions which contain a subset of the VS projects from the "master" solution. These could be split by business area or by team, for instance. This seems like more of a “nice-to-have”, unless you anticipate your solution getting really large
- Similarly to the last point, if your Sitecore instance ever needed to be split up into two or more smaller instances, the VS project-per-module approach would make this split a lot simpler - you would “simply” need to work out which Helix modules need to live with each new Sitecore instance and create new solutions for each subset
Allowing your Helix modules to live across multiple Visual Studio projects
If you have decided you don’t want to go down the VS project-per-module approach for your Helix implementation, here are a few suggestions of different approaches you could take, and some thoughts about the implications of those decisions. For all of these approaches I’m assuming that Helix module separation is still present in some form, and the Helix dependency rules are still respected: solution folders can serve as containers for module artifacts, rather than Visual Studio projects.
Ask yourself the following questions to work out which direction you might want to go in when thinking about your Helix module -> VS project mapping:
- Do you want to group your non-code artifacts?
- Do you want to share any of your Helix modules with solutions belonging to other Sitecore instances?
- This can be tricky due because you will usually require more strict versioning; it probably makes sense for the shared functionality to live in a separate VS solution/source control repo, and to be integrated with its consumers via an internal NuGet feed (so that consuming solutions aren’t forced into the same release cadence as that of the shared module.)
- Do you have a separate team of front-end developers who would like the VS solution structure to fit with their preferred ways of working?
- Can your Feature/Foundation modules be grouped into logical subsets?
- If so, you could consider opting for one Visual Studio project per “group”. Alternatively, you could opt for just one VS project for each entire layer, with solution folders for each module name containing your code (and the code namespaces matching this convention). For either option, if you’re including non-code artifacts then these projects will be web projects rather than class libraries, with top-level styles/script/views/config folders split into subfolders by module just like in Habitat
- Are there any other factors specific to your situation?
- Remember, the Helix guidelines are only there to facilitate development productivity. Don’t lose sight of your ultimate purpose by getting too bogged down by the details of Helix. Break the rules where it’s pragmatic to do so.
Ultimately you’ll need to weight up the pros and cons relative to your specific implementation and your team to work out how you should implement Helix. Sitecore will eventually be publishing some official “non-Habitat” VS solution structure examples, so keep an eye out (take a look at https://github.com/Sitecore/Helix.Docs/issues/21 for the related discussion.) I’m sure that some “winning” solution structures (and supporting tooling) will emerge over the coming years, as the community continues to try and pit the Helix philosophy against the real world.