Setting Up Your Sitecore Project for Success

March 9, 2016

Blog | Technology | Setting Up Your Sitecore Project for Success

In my career I’ve seen many different ways to set up a Sitecore site.  In fact, I believe almost every site that I’ve seen has been different than any of the previous sites I’ve worked on.  In contrast, at GeekHive we try to limit the variation between projects. This reduces ramp-up time for new developers and creates a coherency that improves efficiency.

Below is a list of of bigger ticket items that we find work to set up your Sitecore Project for Success across most projects (even existing projects).

Setting your Sitecore Project up for Success Best Practices:

 Detailed Project Setup Instructions

The first step with either a new project or a newly acquired existing project is to compile an extremely detailed document outlining project setup.  Without a document like this in place you’ll find the need to pull away existing developers in order to ramp up new ones.

The setup instructions should go into excruciating detail and highlight any abnormalities that may arise due to differences in local developer computers or 3rd party applications or varying versions (taking the time to do this will save you headaches down the road). It’s extremely satisfying to set up a project step by step, build the project and then open a browser and see a fully functioning site that is ready for more code.

Separate Sitecore Core from Custom Code

One of our goals with the setup of our Sitecore projects is two-fold:

  1. Install a new Sitecore site using the installer from SDN – For example, (per setup instructions) install the Sitecore X.X rev. XXXXXX.exe application
  2. Build (copy) custom code from solution to the web root directory outlined in Step 1

This practice ensures that we’re not bloating our solution, or more importantly, source control with files that are unchanged.  We still bring in Sitecore DLLs as references when needed and rebuild over the existing DLLs.

This concept is also in-line with best practices when considering Sitecore upgrades.  It can make it much easier to determine what files were changed and require more attention during an upgrade.

We most often use Team Development Suite’s (TDS) file deployment ability to satisfy this requirement. If TDS isn’t an option, the local Publish to File System option in Visual Studio works similarly.

Automated Item Generation

At GeekHive, we’ve chosen TDS as our Item Generator for all of our Sitecore projects.  We’ve developed custom libraries that provide extensions and helper methods that developers become accustomed to as they move from project to project.

There are many automated item generators available for Sitecore. While TDS is our choice, others work well too.  The most important concept is to HAVE one. While it’s possible to manually build the classes for templates, it’s ultimately time that could be spent working on functional parts of the application.  Computers are work horses – their one job is perform a series of tasks very, very quickly – so it makes sense to leave this job up to your processor. On top of the time that’s saved, it’s also much less error prone.  Issues are typically found during build time instead of compile time. The output of item generation is strongly typed classes that make code cleaner, and more powerful inheritance and interfaces that anyone could write by hand.  Our typical class generation file is 5,000+ lines long. It’s difficult to justify typing that out by hand.

Avoid Modifying Default Config Files

It can be argued that Sitecore is constructed completely by configuration files.  At each stage of the application life-cycle you’ll find an exhausting list of pipelines, events, agents, etc. that work together to make Sitecore what it is.  With each new Sitecore version, this framework changes slightly.  For this
reason it’s not recommended to modify the stock config files.

Sitecore has a fantastic ability to allow config patches to be applied to any node within the node in the default web.config file.  You can patch in new processors before or after specific elements, patch in specific attributes, or even completely remove elements.

When performing an upgrade, the lower the number of config changes that are required the less headaches there’ll be.

Automating Builds/Deployments

Specifically regarding the test-style environments (QA, Staging, CI, etc.) it’s very important to have a build infrastructure in place prior to pushing code.  On projects with a poor or non-existent build infrastructure the thought of performing builds is daunting.  There are many steps involved, a significant amount of time and lots of potential for things to go awry.

Whenever possible, we argue for the inclusion of a solid build infrastructure prior to the first deployment with the client.  When a project is in full swing builds may be occurring once a week or once every other week.  It only makes sense to provide a “button” to be pressed as opposed to 4-6 hours of a developer’s time that can be spent better elsewhere.

Conclusion: What does a successful Sitecore set up mean for your clients?

We often implement many of the above techniques into acquired projects as well.  Some pieces are easier to incorporate than others, but we do the best we can.  Spending a little bit of time in the beginning of an acquisition to normalize the landscape will pay itself back in dividends as the project continues.  It’s all about providing uniformity without sacrificing the developer or projects ability to achieve its goals.

Implementation of these techniques is cost-heavy up front, but following these guidelines sets up a project for long term health. Each one of these items keeps the client’s best interests in mind.  When approaching a client with these ideas this point should be stressed.

Our developers have grown so accustomed to these approaches that they often groan when a project doesn’t implement them.  While this does cost money up front and your client may not see an immediate benefit, we feel that with little difficulty these concepts can be expressed to the client.  The primary goal between the early interactions is to assure your client that these steps ultimately save them money and will result in a better outcome.  Greater efficiency equals less money and a more consistent product.

John Rappel

.NET Practice Lead
  • Best Practices
  • Development
  • Patterns & Practices
  • Productivity
  • Sitecore
  • Workflow

Recent Work

Check out what else we've been working on