The story of my Helix implementations Build your own Habitat Presentation Discussion

My experience with Helix Multisite with Helix architecture using Unicorn Habitat module for Sitecore Hackathlon 2016 made for fun Multisite with Helix & TDS built according to best practices Sitecore marketplace module using Helix architecture which didn’t go well (standard n-tier application with habitat build process)

What is Helix Architecture Number of dependencies vs Effort Why habitat was created? Situation when you change one thing and spent a lot of time on modifying, testing dependencies and you still not sures

Helix Architecture Smart approach to create complex websites

First decission: TDS or Unicorn? Usually: In Helix: >> > It’s customer (budget) driven anyway…

Helix on Unicorn Hint which item belongs to which project is great Projects dependencies in configuration works (and can be checked globally on unicorn.aspx page)

Helix on Unicorn Convenient deployment on local machine with Habitat gulp scripts (deploy selected layer, auto-deploy CSS, cshtml…) Can deploy selected configuration (like only features of particular website) using unicorn.aspx. Rainbow Code Generation is not as straightforward as TDS Memory issues in build script, if syncing whole solution with huge numer of items: Change scripts/unicorn.js: var syncScript =__dirname + "/Unicorn/./Sync.ps1 -secret " + secret + " -url " + url; var options = { cwd: __dirname + "/Unicorn/", maxBuffer: 1024 * 400 }; Orphant items in sync directory Rainbow – unicorn’s serialization provider If something doesn’t work few times developers stop using it at all…, so developers stop to use syncUnicorn task, stop to use default task

Helix on TDS Even more projects - XXX.Feature.YYY, XXX.Feature.YYY.Master, XXX.Feature.YYY.Core) Project dependencies can’t be displayed in single location (you don’t want to open every project…) Not easy to sync selected layers or projects (only one or all). TdsGlobal.config + Deploy Solution Sync all TDS Projects using History TDSGlobal.config + Deploy Solution will deploy code and items according to settings: <SitecoreWebUrl>http://habitat.dev.local</SitecoreWebUrl> <SitecoreDeployFolder>C:\Websites\Habitat.local\Website</SitecoreDeployFolder <DisableFileDeployment>False</DisableFileDeployment>…

Helix on TDS Deployment is slow. Hedhehog has solution for this - use one TDS project with rules http://www.hhog.com/blog/sitecore-helix-fxcop-rules) Problems with namespaces in code generation Use your own .tt files. Header Transform File: using GlassMapper.Sc.Fields; using Sitecore.Data …. using SmartSitecore.Foundation.PageBase.Models; //location of GlassBase class Github sample without code gen and it’s not as supported as Unicorn code. No gulp tasks usage – need to modify the one for Unicorn. Anyway works surprisingly good TDS is not able to genetate proper namespace when using Code Generatation Target File „Model/TdsClassses.cs” and „Base Namespace”. I contacted hedhehog directly but we couldn’t find the solution, cause proper namespace is not available

CI/CD deployment of Helix with Unicorn Code Standard way with Web Deploy or Octopus. If you keep the convention easy to deploy single site only in multisite solution (because of folders separation). Items via Unicorn Copy .yml from selected folders to synchronization directory on the server (possible via nuget package, or Octopus) Automatic sync of selected configuration (layer or project) with Octopus script: https://www.sitecorenutsbolts.net/2016/03/14/Octopus-Deploy-Step-for-Unicorn-Sync/ Aggregation project doesn’t have the items, only „Package Bundling” in settings How to decouple projects when we use TDS .csproj files. How to place TDS .csproj in nuget package?

CI/CD deployment of Helix with TDS Code Same as Unicorn Items via TDS Aggregation project to improve performance and remove not needed content items. It will create single .update package file. Deploy as usual with Sitecore Package Deployer or Sitecore.Ship Nuget package with items: Aggregation project doesn’t have the items, only „Package Bundling” in settings

Developer/Architect’s Helix Concerns Traditionally you divide page and project by components. With helix you think more about business features.

Is it a Feature or Foundation? If you know all the details at startup, plan it. If not don’t care too much, it can be refactored easily. Refactoring is rather easy, because of limited number of dependencies We have a project where we have just a big picture of whole, but busiess is adding features one by one

Component = Feature? Feature may be something bigger than single component Traditionally you divide page and project by components. With helix you think more about business features.

But if… Feature depends on another feature Split it, instead of moving whole feature to foundation layer, just because other features have reference to it.

More tips Avoid too atomic features – you will end with hundreds of .csproj If you place too much code in Foundation, it become Feature (remember: Foundation = stable code) Document your projects (after 3 months you may not remember what is your 58th project about) All official samples are without Solr, Glass.Mapper and auto-generated model classes Hundreds of projects = build and deploy performance impact Looking forward for Sitecore 9 sample

Other Benefits of Helix architecture Code merging (for fans of merging TDS .csproj with hundreds of items) Build your VS templates for your projects or use https://marketplace.visualstudio.com/items?itemName=AndersLaublaubplusco.SitecoreHelixVisualStudioTemplates Architecture is well known, easier onboarding proces for new developers

Implementing helixed sitecore module Architecture is great for this Single Feature or Foundation .csproj = Module Looks good on your github 

Thanks. Tomasz Juranek http://smartsitecore. com https://www. linkedin