Start an empty project with Helix

27 februari 2018 om 00:00 by Maria Fel - Post a comment

After some break from doing development on top of Sitecore CMS I came back and started my way with a deep dive into Helix principals and investigating examples and existing implementations. As everyone does I really like the idea behind the Helix principals in a way how it fits for Sitecore projects.

But I found out that it is still quite difficult to setup a new project from scratch...from empty solution (so not copying Habitat and then clean it out LOL). I took a look into the Habitat implementation, scripts,  VS templates, but it was not fast, it was not clear enough how to take into account dependencies, packages,  and  how to be able to keep it all up to date during the project timeline/lifecycle.

I started thinking about how to create an empty start point for the project based on Helix principals.

I came up with the simple idea to include templates for Feature/Foundation/Project/Test + whatever into the solution. That makes templates that you use visible. And because of that it is easy to maintain and customize them for project needs. Once you customize it, you have your basic Helix instruments for the project, that can easy live and be changed during project life cycle.

I would like to share the way how I see it can be done. My approach consists of 2 main parts: Helix setup and build script.

Before I start with technical part, I would like to mention people who helped me a lot here.

For Helix ps scripts, I would like to say “thank you” to Marc Duiker. I used his scripts as a starting point and changed them when it was needed.

https://gist.github.com/marcduiker/75a5aadffa8e8bec953dc936500a13c0

https://blog.marcduiker.nl/2016/12/29/hands-on-with-sitecore-helix-anatomy-add-helix-powershell-script.html

For the build script idea, I would like to say “thank you” to Ruud van Falier.

Let’s start with solution structure:

 (code can be found at https://github.com/mfel/Heli):

Prerequisites:

Solution Explorer:

What is the difference from usual setup?

The Feature, Feature.Tests, Foundation, Foundation.Tests, and Project template projects are now located under the Configuration folder as a part of the solution.

There is a PowerShell project Scripts that contains 2 folders: Build and Helix. Build contains instruments for local build and publishing processes, whereas Helix contains instruments for Helix modules creation.

As you see in the Solution Explorer we now have all Templates under the Configuration folder. That gives us the opportunity to quickly review, check, add, delete, modify dependencies via NuGet Package Manager for each Template. We can extend them with TDS templates as well in case we use TDS as a serialization provider, or add GlassMapper dependencies when needed. The same goes for Test Projects. For example, we can add dependencies to FakeDB for Foundation Test project, but we omit it for Feature project and have a dependency there only on Moq.

(This setup is an instrument for development, so it can be excluded during the deployment for Acceptance, Production)

Folder Structure:

It is the common structure for Helix projects:

folder structure

Configs settings:

This setup has 2 configs:

  • Add-helix-module-configuration.json
  • Build-publish-configuration.json + publishingsettings.targets (I will put more details in build script section about it!)

These configuration files are the only point to specify location for certain folders.

Publishing targets in this setup are also defined once and used to deploy every Module in solution. This is done to speed up publishing process for whole solution. You can still have publishing targets per project, for needs to deploy only particular module. So, this possibility is still in place.

I also added Profile.ps that contains paths to the scripts to easily use it in PackageManagementConsole.

How does it work?

First, download solution template from https://github.com/mfel/Helix

Open it in VS.

Second,

Modify configs:

  1. Add-helix-module-configuration.json
    • featureNamespacePrefix
    • projectNamespacePrefix
    • foundationNamespacePrefix

  2. Publishsettings.targets
  3.         <publishUrl>YOUR_PATH_HERE</publishUrl>

  4. Build-publish-configuration.json
    • "slnName": "YOUR_SLN_NAME_HERE.sln",
    • filesToExclude. Here I have[ ".Test.csproj", ".ModuleName.csproj", ".ProjectName.csproj", ".FeatureName.csproj", "FoundationName.csproj", ".ModuleName.Tests.csproj", "Scripts.pssproj" ].

It can be expanded with for example TDS modules.

Configuration part is now finished.

Next part is to adjust/customize templates for Project, Feature, Foundation, Tests.

This simply can be done via the Package Management console and by just editing the current structure in a way that you would like it to have.

When this part is finished we have our instruments ready for use.

To see it doing its work, open Package Management Console and run

"D:\YOUR_PATH_TO_FOLDER_HERE\Helix\configuration\scripts\Helix\add-helixmodule.ps1"

It contains 3 functions:

  • Add-project YOUR_PROJECT_NAME_HERE
  • Add-Foundation YOUR_FOUNDATION_NAME_HERE
  • Add-Feature YOUR_ FEATURE_NAME_HERE

Each function will create a specific module and its accompanying Test project.

Let’s look at what is done so far for build-publish to local folders.

Local-build-publish.ps1 contains one method Run that does the following:

  • it executes Build for SLN
  • After that it parsesthe sln file and copies ContentItems to the target folder.

The main idea is to not run build and publish commands per project, but instead build the solution once and then copy necessary files in a way: parse sln file, collect all projects that are included (+ exclude the ones that are in the property  ‘’filesToExclude’’ of  Build-publish-configuration.json) and copy all files that are mentioned in csproj files to the destination folder (destination folder is in the  Publishsettings.targets).

The benefits of this approach are 

  1. It is faster than to run “Publish” for each project separately.
  2.  It copies only files that are included into the projects, not everything that is in the file system.

The script does not do any front-end operations by design. It gives you an opportunity to be free to choose any front-end framework/setup and add necessary scripts.

Nieuwste