March 24, 2013

Configuration Settings for Developing a Multi-Site Sitecore Instance with Multiple Developers

By: Craig Taylor
March 24, 2013

Confusing configuration
Confused about which direction to go in with regards to your configuration files in Sitecore? It can be overwhelming to consider all the different options for configuring a solution for a new project. There are many different ways and you have to wade through the options to come up with the best approach.

Over my years of architecting and developing Sitecore websites, I've learned that you should always plan for the possibility of a single-site Sitecore instance to turn into multiple-site Sitecore instance. You should likewise consider the possibility that there will be multiple developers developing these multiple sites. It would be advisable to put in the time now to make sure you aren't accidentally overwriting code later when a looming deadline is approaching and everyone is under the gun.

Basic Solution Architecture

Let’s get a baseline for the types of Visual Studio projects that I have in a basic site Visual Studio solution. Each site is unique in its requirements and there are likely to be exceptions, but for a ‘normal’ site, I will have five basic projects in my solution as follows:
  1. A Web project
    • This project contains the presentation layer components that are used to build the Sitecore website. This includes Sitecore layouts, sublayouts and renderings. The project also contains my site’s CSS, Javascript and any static images not controlled by Sitecore.

      I’ll elaborate on the Web project configuration and the specifics of how to keep multiple sites from stepping on each other’s toes in a future post.
  2. A Team Development for Sitecore (TDS) project
    • This project contains the references that tie back to the Sitecore items for the website. This includes layouts, sublayouts, renderings, templates and sometimes content. TDS enables Sitecore items to be versioned in source control and can also automatically build and deploy Sitecore packages.

      Note: A TDS project can only be tied to a single database. If your project is tied to objects in the Master database and you additionally have changed made to the Core database that you would like to keep in source control, you will have to create a separate project for the Core objects.

  3. A Library Project
    • This project will store any common functionality that can be utilized in multiple locations across your solution. Common classes here include Utility and Settings classes. I also store the object glasses generated from the Custom Item Generator Module in this project.

  4. A Configuration Files project
    • This project contains configuration files that apply only to specific developers’ machines. These files are used for local builds and will not be included in packages that are used for integration testing in a shared development environment. The files included here might be “ConnectionStrings.config”, “DataFolder.config” a customized “Web.config” or “SiteDefinition.config.” Each developer will have his/her own directory structure in this project.

  5. An Instance Configuration Files project (optional)
    • This optional project contains the instance-wide configuration files for Sitecore and can be shared across ‘n’ number of site solutions. The only environment that will include its own folder structure here within this project is the shared development integration environment.

      I list this project as optional because there are times where you won’t want to have too many developers’ hands in the configuration files that affect an entire instance. I keep this project separate from my site project solutions in source control.

      Note: The files included in this project affect an entire instance. If changes are made to these files and committed to source control, they will be changed on the instance and they can potentially affect every site on the instance.

Solution explorer configuration

With this basic definition of projects for a Sitecore solution, let’s dive deeper into how we can manage the configuration files for multiple sites and multiple developers.

Configuration Files

Configuration files come in three flavors and can be located in three separate locations within your solution architecture:
  1. Instance-wide configuration files
  2. Instance wide configuration
    • Stored in the ‘Instance Configuration Files’ project. These files are common to all sites and can be changed by any developer with access. Changes affect all sites on the instance.

  3. Project-specific configuration files
  4. Project wide configuration
    • Stored in the ‘Web’ project. These files are common to all developers of the site and can be changed by any developer for the site. Changes affect only the single site.

  5. Developer-specific configuration files
  6. Developer specific configuration

    • Stored in the ‘Configuration Files’ project. As long as the developer is changing the configuration files within his/her own directory structure, the changes made to these files only affects a single developer.

Solution Configuration

To maintain the configuration files and local builds, each developer should additionally have a solution configuration specified for that developer. This enables ‘Developer 1’ to maintain specific build settings in the solution file that builds and publishes the projects in a particular manner and those build settings can be completely different from ‘Developer n.’

Solution configuration

Wrap it up

At first glance, it looks like there a lot of places to make configuration changes with this architecture and it can be difficult to know where to go to make the changes. In practice, it quickly becomes second-nature to know where to make your changes as 95% of those changes are going to be in the developer-specific configuration files contained within the ‘Configuration Files’ project.

One way configuration
Okay, so maybe there isn’t just one way to configure your Sitecore solution, but I believe this is a good approach that can scale nicely as additional sites and developers are thrown into the mix.

Regardless of the perceived complexity involved in this architecture, the benefits of being able to manage multiple sites and multiple developers without changing configuration settings each time the latest version is pulled down from source control is immeasurable.