Tips and tricks for Sitecore code review processes and tools
By: Sitecore MVP Glen McInnis
Our extensive experience with Sitecore development has led to the creation of many best practices and code review processes. We share a few tips and tricks for you to include in your next project:
Coding standards and code reviews are not new concepts; however, the application of this vital quality and learning technique can seem either unclear or overly complicated when attempting to apply it to Sitecore.
Challenges to implementing code reviews
- Sitecore introduces specific conventions and patterns that are not known to other .NET code quality tools. A large part of a Sitecore solution’s “code quality” comes from structures in the database, such as data templates.
- Even though the long term benefit is present, a pressing timeline might necessitate the slimming of certain practices like code reviews.
- A code review can happen after a significant amount of work has been done. This can lead to resistance to change, or following from the first point, or a lack of time to address valid feedback.
To create a holistic approach for code review that allows for immediate or near immediate feedback we recommend:
- Use tools like ReSharper and Visual Studio code analysis: these can pick up common .NET errors early. If code analysis takes too long on build, consider moving this to the continuous integration server. Developers can continue to work, but a failed code analysis will trigger broken build notifications.
- Content editor gutters: Certain Sitecore practices are not about code, but instead are dependent on database entries. An example might be that you expect all items to be in a final workflow state or certain items should not have presentation. In cases such as this you may consider implementing custom gutters to surface this information in the Content Editor. Some of the gutters in our implementations (native and custom) include:
- Sitecore Rocks allows developers to execute Sitecore Cop against an item or an item and all descendants. Sitecore Cop will check for some general Sitecore practices, but to capture your design decisions and code standards you will likely want to create custom validators. If that is the case, I would recommend TDS validators over Rocks.
To create custom validators you can create classes that implement the [Validation] attribute. A nice summary post can be found here.
- The final approach is Team Development for Sitecore (TDS) validators. If you leverage TDS it is possible to run validations at build time. For each Sitecore item in your TDS project the selected validators will be executed. I personally prefer this over Rocks and gutters as you do not have to remember to run the validation. We have created several custom validators to enforce naming and usage conventions to ensure consistency. You can see in the following Visual Studio screen capture several checks for workflow state and template usage.
To create your own TDS validators create an assembly:
- Reference the following DLLs from C:\Program Files (x86)\MSBuild\HedgehogDevelopment\SitecoreProject\v9.0:
- HedgehogDevelopment.SitecoreCommon.Data.dll
- HedgehogDevelopment.SitecoreCommon.Data.Parser.dll
- HedgehogDevelopment.SitecoreProject.Tasks.dll
2. Ensure your assembly (AssemblyInfo.cs) contains the attribute:
- [assembly: ContainsValidators()]
3. You must then implement classes by inheriting from HedgehogDevelopment.SitecoreProject.Tasks.ProjectAnalysis.UserConfigurableValidator.
4. We’ll not bore you with all the details of the code in this post — you can download a full example here.
5. Once you have your assembly you can deploy it to C:\Program Files (x86)\MSBuild\HedgehogDevelopment\SitecoreProject\v9.0. After a Visual Studio restart TDS should pick up our custom validators and show them in the configuration panel.
Hopefully with these tools you can catch most issues early in the process. We would still recommend that the team undertake peer reviews — nothing can really beat the review of a set of seasoned experts.
