Step by step guide to add Serialization project to an "empty" Sitecore Helix solution

In this blog post I will give a step by step guide to add a Serialization project to an "empty" Sitecore Helix solution.
I created a guide to setup a clean Helix solution in this blog post.
I will add a Serialization project into this solution

In my projects I usually have a simple template for Foundation projects and another template for Features. The Feature will have references to Glass Mapper, extensions and more.

If you want to have different templates for Foundation and Feature projects look at my previous blog post for an example on how to get you started.

The steps

1. Run the command Add-Foundation Serialization (Package Manager Console)

2. Add unicorn to the project from Nuget 

3. Unicorn.UI.DeployedContentEditorWarnings.config.disabled

This file configures Unicorn to throw up warnings and prompts when saving items that are included by Unicorn. On CM servers we would like this to be enabled.

For Sitecore 9 this will be enabled correctly based on the server roles.
The role required here is ContentManagement for it to be enabled.
In development we are using the Standalone so it won't be enabled.

For my other Sitecore 8 sites I enable/disable these files based on a csv file as the first step in VSTS release.

4. Unicorn.zSharedSecret.config.example  

• Rename the file to Unicorn.zSharedSecret.config
• Generate a secret key and add it to this config

5. Setup the Unicorn PowerShell

• Create a new folder UnicornSync (under the Serialization project in Visual studio)
• Get the Sample.ps, Unicorn.psm1 and the .dll from the nuget package.
• Rename the Samle.ps to Unicornsync.ps1 and configure it for your solution.
• Add the same secret key you added in the Unicorn.zSharedSecret.config
• Make sure the .dll is referenced.

6. Add Rainbow settings

<setting name="Rainbow.SFS.SerializationFolderPathMaxLength" value="150" />

<setting name="Rainbow.SFS.MaxItemNameLengthBeforeTruncation" value="50" />

7. Add Unicorn.Helix.config

This file I collected from the example solution Habitat (2017)
I removed the roles and users configurations. I changed it to include the setup I think will be needed for most of our projects.
You can look at my Helix file here

This config has the following line in the configuration:
<targetDataStore physicalRootPath="$(sourceFolder)\$(layer)\$(module)\serialization" useDataCache="false" singleInstance="true" />
 
You need to add sourceFolder for your instance to make this configuration work.

<sitecore>

  <sc.variable name="sourceFolder" value="C:\Sitecoreprojects\myHelix\src" />

</sitecore>

8. Create folders under Templates and Renderings

Create these folders under Templates and Renderings(give them some unique icons)

9. Under Layouts create a Project folder

Additional notes

Load order for Unicorn

In my first blog post I added some logic to have multiple module templates.

In these templates I would advice to add correct load order for Unicorn so you don`t end up with loading unicorn projects in the wrong order. The project grows and more dependencies should be added to the module templates.

In my starter Foundation projects

<configuration name="Foundation.Helpers" description="Foundation Helpers" dependencies="Foundation.Serialization" extends="Helix.Foundation">

In my starter Feature Projects

<configuration name="Feature.mytestfeature" description="Feature" dependencies="Foundation.*" extends="Helix.Feature" >

In my starter Project Projects

If you have a common project add this as dependency for the other projects

<configuration name="Project.TestHelix" description="Project" dependencies="Foundation.*,Feature.*" extends="Helix.Project">

Example on how to have different sourceFolder/settings for different environments

The sourceFolder path would usually be different on developer machines, test servers and production servers.

For development I like to add dev.settings.config.example and dev.settings.config which I add to source control.
dev.settings.config contains the variable for sourceFolder. site settings with database="master" and other settings that reduce the time Sitecore starts after a build.

When a new developer is introduced to the team I instruct them to change their dev.settings.config so the sourceFolder is pointing to the correct path and other settings if needed.
I like to put this to build action none and tell them to push it when needed to their local site.

I add these files to a new folder zzzDevelopment, I can then easily delete all of these files in release with VSTS. we don`t want our dev settings on live servers.

For production/test servers
I create two additional folders zzzProduction and zzzTest.

Under the zzzProduction folder I add a new config SiteSettings.config.disabled where I add the sourcefolder path for production and the site definition.
This is set to disabled so we don`t mess up our development. I use a PowerShell script to enable/disable this and other files in our VSTS release step.

For a cleaner setup you should divide them into seperate files sitesettings, and sitedefinitions.

In our Release step I delete all the files under zzzDevelopment so they are not added to the production/test servers. I also delete test configs from production and production configs from test.

I do the same for zzzTest folder but add the testserver settings.

In this blog post I based my setup on Sitecore 8, I will test the role configuration in Sitecore 9 later to see if this can improve the setup. I think the enable/disable PowerShell script can be removed and we might not need to set test/production files to .disabled.