Team Development with Sitecore the Easy way

Most of the Sitecore implementations I'm involved in have me working in a team environment. In fact, this is pretty normal for any IT project. Although a team environment has many benefits, there are also some complexities that need to be addressed in terms of keeping the development environment in sync.

There are two things that need to be synchronised across all the development environments; code and data. The code synchronisation issue has been dealt with long ago by using source control. I wish I could say at this point that I haven't encountered a team not using source control for a long time, but alas I cannot. Realistically I cannot believe that any professional developer would not use source control these days. This is the number one tool required for easier team development for any project.

I also use source control for 1 person projects. Along with synchronisation, source control provides other benefits such as versioning of the code so you can roll back changes, and providing a central location for all code. New dev comes onto the project? Just get the source from here. Old project needs maintenance? Just get the source from here. Original developer left the company? Just get the source from here.

The other part to the synchronisation issue is the data. I'm a strong believer of putting all database related things in source control. Your development database on a SQL server is just an instance of the structure and data you define in script files. Do not treat the database server as the place where your database lives. It should live as scripts in source control. The database on the database server is just a single instance of that database.

Another benefit of storing your schema and data in source control is the ability for accessing the data without a direct connection to the database server. For example, when working from home or a remote location away from the office. If the database scripts are kept in source control it's straight forward to get the latest versions of the files and create a local copy to work against.

Although I want my data to live in source control as scripts I also am a strong believer of not accessing proprietry databases directly if an API exists. This is the case for Sitecore. Not to mention the complexity of the data stored in Sitecore.

So when working with Sitecore, how do you get your data to live in source control rather than the database? A common practice for Sitecore projects is to create Sitecore packages of the project specific data. This package can then be put in source control. This can also be seen as common practice through many of the shared source projects for Sitecore. Problem here is the package is a zip file, not text so your source control will not try and merge the package if multiple developers have updated multiple items and updated the package independent of each other.

Sitecore 6 introduced item serialization. This allows you to export item data in a text format at the click of a button to disk. And also to import it at the click of a button. This is a much better approach than the package approach. The only drawback to Sitecore 6 item serialization is that media library items cannot be exported in this way, so you'll still have to drop back to a package for these.

So now we have the data on disk, we can include it in source control. Well... it depends on your project structure how easy this will be. The item data is placed on disk under the data/serialization folder. I don't like to write my Sitecore code in the same folder that Sitecore runs. I like to separate my custom code from the system I'm building on top of, so in source control I don't have the Sitecore root at the same location as my dev root. This makes including the serialized items more difficult.

Now let me step down off my soapbox and confess that although I want my Sitecore items in source control, generally I don't do this due to the reasons listed above. At Next Digital we normally have a shared development database with each developer running their own instance of Sitecore. This normally works quite well due to the fact that this environment is development and each instance of Sitecore (on the dev's machine) is restarted due to code changes quite often. This restarting means there are minimal issues with caching of the data.

OK, so now for the easy way. I was privileged enough to be included in the beta program for a new team development tool for Sitecore. I would like to introduce you to "Team Development for Sitecore" (or TDS for short). TDS is developed by Sitecore partner Hedgehog Development in North America. It is a plugin for Visual Studio which allows you to serialize and deserialize Sitecore items for your project directly from within Visual Studio. The items can also be added to source control as the items exist in a custom TDS project as text files. Being text files most source control system should have no problem merging changes.

You'll notice from the above screenshot that the text format of an item in your TDS project is the Sitecore 6 item serialization format.

TDS also allows synchronising the items in your project with your Sitecore server. You can also select which items to sync and which ones to leave alone.

In general you'll only want to sync project specific items and leave the Sitecore standard items alone.

There are multiple synchronisation options to determine how TDS should handle such cases as when an item exists in the project but not in Sitecore and when an item exists in Sitecore but not in the project.

Another nice feature of TDS is the item designed. Hedgehog built on the concept of the Visual Studio Class designer to provide a similar tool for viewing the relationship between your templates. This is a huge help, especially as Sitecore supports multiple inheritance through templates which can lead to lengthy investigations when trying to work out which template defines which field on an item.

I find it very useful when designing a solution to design and rework the templates in a UML diagram. The item designer at least gives you the view part of this.

Overall I think TDS is a very good start. There's heaps of potential there, like making the item designer allow updating of templates and relationships. I'm quite eager to see what Hedgehog do next with TDS. Even so, just having the ability to synchronise Sitecore items across multiple locations is worth the price tag.