Dusty Eves


Sitecore Architect with Paragon Consulting

Effective Use of Hedgehog TDS


Team Development for Sitecore.  If you’ve ever experienced the pain of trying to work as a team on a Sitecore project without it then you know it pays for itself many times over when compared to working without it.  I remember a particular project where we were literally burning scores of man hours a week in trying to get all the developers back on the same page.

TDS is utterly indispensable in Sitecore development, something those of us who’ve spent years working with it take for granted.  As such, there’s not a lot of literature to be had on making effective use of the tool.  To remedy that, here are my guidelines for how to setup and get the most out of your TDS solution.

Two Projects

At the heart of Sitecore exists an odd philosophical question: Where is the line between technical artifacts and content?  At a fundamental level, everything from the presentation definition to the text of the header widget is, at a purely technical level, content.  Layouts, renderings, templates, and branches are all items that are clearly development artifacts but the pages and content pieces they compose as well as the initial site structure are development responsibilities at least up to the point of go-live. The best solution that I’ve found to this is to have two separate projects.


  • Templates
  • Branches
  • Layouts
  • Renderings
  • Settings


  • Initial Site Structure
  • Meta Content (Dictionary Items)
  • Media Library content

TDS.Content Project

The idea of holding site content in source control is somewhat antithetical to the idea of a CMS, but the initial content loaded is certainly necessary to get the site up and running.  At the same time, the content is certainly not the responsibility by the development team and keeping it in TDS after go-live creates a risk of overwriting.

To eliminate the risk of overwriting live content, all items in the TDS.Content project should have their Item Deployment property set to DeployOnce. Under the properties tab of any TDS item is a deployment option.  DeployOnce does exactly what it sounds like in that any item thusly marked is only deployed if the item is absent.  This allows the dev team to support the initial site structure without the risk of overwriting content author changes.

 Glass Mapper class auto-generation

Developer preference on this subject varies but auto-generating your glass mapper objects can save you a lot of time and effort.  The most common objection that I here to auto-generated templates are concerns about not being able to directly control the mapping objects. While not directly controllable the default templates that ship with TDS build all interfaces and classes as partials, making them every easily extensible.

I won’t go too into detail on the how-to with code generation, as there’s a great tutorial to be found here.

Like what you see? Something I missed? Have an even cooler way to do the same thing?!?! Let me know in the comments below.

Leave a Reply

Your email address will not be published. Required fields are marked *