Sitecore End to End, Part 2 - Project Setup

Monday, June 03, 2013 @ 01:42

A look at the development workflow of a Sitecore Project from inception to production.

Series by Jon Upchurch, Matt Gartman, and Josh Jenkins

By: Jon Upchurch, Senior Developer – I want to start by prefacing this article with a caveat. This is meant to describe how we set up our solution and how we configured our tools. If you’ve arrived here looking for information on how to setup Visual Studio, Mercurial, TDS, etc. then you will want to look at some of the other very good guides on those topics. Here, I’ll be describing how we setup all the tools and such so that we could work efficiently and streamline our workflow.

Some of these steps can be taken in any order as long as the results are the same.

First, you’ll want to create your source control repository.

I prefer to do this first, since I’m human and occasionally mess something up along the way I’ll have some save points to roll back to. In our case we used Mercurial (Hg). I recommend distributed source control over things like TFS or SVN although in the long run any of these solutions would work. All of our initial development took place in the default branch until we started elevating things to QA which will be covered in later articles. Josh’s articles here (regarding project setup) and here (regarding Mercurial) go into more detail than I want to cover here. I heartily agree with Josh that source control should come first as a matter of good practice.

Second, create your Visual Studio Solution and file structure.

Continuing along what Josh outlined to begin with, we ended up with the following root directory structure that worked very well for what we ended up using:

/documentation                                              
/lib                                                                         All of your binary references go here
/packages                                                           Created by Nuget as you install packages
/src                                                                        Your source code folders
/tools                                                                    Optional

Even if you’re not currently going to be using multiple Sitecore sites under a single instance, it’s a good idea to abstract the common functionality from the project functionality in case you can reuse it elsewhere. The following is similar to what we used:

/src/Common
/src/Project1
/src/Project2
… etc.

Beneath /src/Common/ we create a class library project and matching folders as follows:

/src/Common/Common.Core.Constants/ (with class library Common.Core.Constants)
/src/Common/Common.Core.Model/ (with class library Common.Core.Model)
/src/Common/Common.Infrastructure/ (folder only)
/src/Common/Common.Infrastructure/Common.Infrastructure.SitecoreExtensions/ (with class library Common.Infrastructure.SitecoreExtensions)
/src/Common/Common.Website/ (folder only)

And the same concept under each of our project specific folders:
/src/Project1/Core/
/src/Project1/Core/Project1.Core.Constants/ (with class library Project1.Core.Constants)
/src/Project1/Core/Project1.Core.Model/ (with class library Project1.Core.Model)
/src/Project1/UI/ (folder only)

It seems like overkill at first to break things down so much but it makes things a lot easier in the long run working with several developers.

At this point you should commit your changes to version control.

Third, install Sitecore in your local IIS.

Sitecore comes bundled with an installer that will handle this for you, but even if you have to do it manually it’s pretty simple. Note: DO NOT install Sitecore inside your project folders!!! You also do not need to put your installation under version control at all. One of the beautiful things about this configuration is that you can run and deploy this to any blank Sitecore instance, and every developer will have their own local instance and local database.

Fourth, copy the contents of the bin folder to the /lib folder.

This will keep the appropriate versions of dll’s in version control and you can reference them all from one place that won’t be affected by anything other than your own projects. You’ll put any other dll’s here as well and reference them in this location instead of the bin folder of an individual project or the website.

And… commit your changes to version control…

Fifth, add Glass and references to projects.

For your *.Core.Model class libraries as well as the Common.Infrastructure.SitecoreExtensions projects you’ll need to add a reference to Sitecore.Kernel.dll (the one in your /lib folder, not from the website!). Then, for each of these you’ll want to open the package manager console and select the appropriate project. Once you do, at the command prompt type:

install-package glass.sitecore.mapper

Repeat this for each of the projects mentioned above (and any other time in this series where “install glass” is directed). This will prepare your solution and add the references to the glass.sitecore.mapper library which will perform all of the Sitecore to object mapping that will make our lives so much easier!

We’ll pick up from here in Part 3: Project Setup Continued.