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 ArchitectureLet’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:
- 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
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.
- 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.
- 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.
- 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.
- 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.
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 FilesConfiguration files come in three flavors and can be located in three separate locations within your solution architecture:
- Instance-wide configuration files
- 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.
- 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.
- 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 ConfigurationTo 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.’
Wrap it upAt 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.
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.