When Helix was introduced back in September 2016, there was a lot of debate in the #helix-habitat Sitecore Slack channel. Was Helix just about principles and patterns or was it also an opinionated way of structuring Sitecore solutions in terms of code and files? If it was only about principles and patterns, did we have to strictly follow the code and file structure described in the documentation. If not, why did Sitecore choose a code and file structure that was hard to create using the current versions of Visual Studio?
In late december, the discussions about Helix steered in the direction of tooling and it came down to the fact, that the implementation structure dictated in the Helix documentation was too cumbersome to work with, too time consuming and that there was no tooling supporting it.
Helix tooling, Helix tooling everywhere!
From here started the development of different Helix toolings, which all had the purpose of trying to solve the problem of making it more easy to work with the Helix implementation structure.
Each of these toolings learned from their predecessors with the goal of not having Sitecore developers base their new Helix compliant solutions on Sitecore's Helix demo implementation/example, Habitat.
March, 2016
Back in the beginning of 2016, when Helix wasn't fully conceived and still came by the name Habitat, Kam Figy created a Yeoman generator for the Habitat structure. This generator enabled the creation of Foundation and Feature projects, including the folder structure and the Visual Studio projects.
Once executed, the generator would create the project files, but you would manually need to add the generated projects to the Visual Studio solution (and create the module specific solution folder as well). In addition, the generator didn't offer a great deal of configuration, meaning that you couldn't easily hook into the project generation and extend it with new logic.
December, 2016
The shortcomings of Kam's Yeoman generator was picked up by Marc Duiker as he took a different approach and chose to use PowerShell to add a new Helix module together with the DTE (Development Tools Environment) in Visual Studio. Marc's script allows creation of Helix projects (Feature and Foundation) much in the same way as Kam's Yeoman generator. The big difference between the two is that the projects being created using Marc's approach are added to the Visual Studio solution.
As noted in his blog post, Marc mentions that the script had to be more robust/configurable, such that it could work with other naming conventions instead on Feature/Foundation. Another issue was that there was no generation of yml files for item serialization (using Unicorn) and finally the script only worked on existing solutions, which means it cannot be used for creating a new Helix solution from scratch.
January, 2017
Most recent, Akshay Sura created the PowerShell script Lets-Rumble, that enabled creating a Helix solution from scratch.
In essence, the script works by guiding the developer through the creation of the solution along with the projects needed in the different layers (Project, Feature and Foundation). Once the creation process is complete, you have a Visual Studio solution with a set of projects added, which follows the best practice of Helix in terms of implementation structure.
The strength of this script is that it's a powerful tool for creating a solution structure with the necessary projects. However, the weakness of the script is that this is a one time kinda deal, meaning that once you have created the solution and project structure, you cannot add more projects to the solution - and it requires you to know all the projects you want to create beforehand.
The Helix tooling of today
Based on the Helix discussions and the already existing toolings, I suggested to my colleagues Emil Okkels Klein and Alan Coates at Pentia, that we could contribute with a tool for creating Helix compliant solutions. We liked a lot of the ideas already out there, but felt that there was room for something that combined the best of breeds, while adding on top of that a configurable and extensible model.
I would like to share the outcome that resulted in our take on a Helix compliant solution generator capable of creating and adding new projects to any layer of the Helix architecture (i.e. Feature, Foundation and Project).
What makes our tooling stand out?
You might be thinking, if this is yet another tool added to the timeline, why should you care about it and what makes it any different then what is already out there.
In my perspective, there are two things that makes our tooling rather unique compared to the existing tooling:
- It works for both new and existing solutions
- It is built by developers for developers, based on practical use cases
As mentioned, the tooling is built to work on both new and existing solutions, which means that you can keep on adding features continuously to the solution and it will just work.
Note: In fact, if you take an existing (non-Helix compliant) solution and put in the correct solution folder structure, it will also work!
On top of that, the tooling was developed based on practical use cases, we at Pentia encountered ourselves on a daily basis - to be honest, we also felt that too much time was spend on creating the Helix compliant implementation structure.
Lastly, but most importantly, the tooling was built by developers for developers. This means that our focus has been on minimizing the barrier between creating a Helix compliant solution, as well as making a tool that is configurable and extensible, which allows us to tweak the tooling to fit the specific needs of our different client projects.
When and how can I use it?
You can start using the generator already today, everything you need to get started is available online. You need to start off by installing Yeoman, which can be done by using npm:
npm install -g yo
Once you have Yeoman running, you need to install the Helix generator:
npm install generator-helix -g
And that's it, you are now ready to start working with the generator.
Step 1: Creating a Helix solution
You can create new Helix solutions by running the following command in an empty root folder, where you want the solution to be created. When prompted, simply answer the questions asked through the creation process:
yo helix
Step 2: Create a new project and add it to a given layer
With the solution in place, you can add new projects to the solution. To do so, run the following command in the root directory, that contains the Visual Studio solution file:
yo helix:add [ProjectName]
Note: You can call the
helix:addwith an optional project name parameter. If you choose not to, the generator will prompt you to enter it.
Once done, you'll have a new Project, Feature or Foundation project added to your solution. If you look more closely on what's being created, you'll notice that you don't just get the file folder structure, the project is also found under the correct solution folder in Visual Studio.
Making the Helix tooling of tomorrow
At Pentia, we are already using the tooling on some of our client projects with success. Although still under active development, it's been great to see the added benefit it has provided to our daily development, since we can focus on more important tasks for our clients, rather then spending 15-25 minutes on setting up new Helix compliant projects to existing solutions.
From the beginning the intension from both my side, as well as Pentia, has been that this tool was meant to be a tool to the Sitecore community, from members of the Sitecore community. This means that you are all invited to participate in the process of making the Helix generator tool an even better tool.
As of now, there are a lot of ideas being discussed over at the issue tracker on the GitHub repo, so be sure to follow along and pitch in with your own thoughts and ideas - no idea is too big or too small.
If you have any questions, don't be shy to drop me a comment or (even better) create an issue over at the GitHub repo! ♥