Do you work in a team delivering Websites based on Umbraco 4.7? Did you ever have to update code and the Umbraco setup, after a site went live? Then you’ve probably struggled a bit trying to synchronize development environments, between developers, test environments and production environments. If you haven’t, this post isn’t for you.

Recently I gave a talk at DUUG, about the setup we’re currently using at Twins, while working on one of our larger projects (which in our case is a project involving a frontend developer, an Umbraco developer and two ASP.NET/backend developers). We saw the release of Courier 2 as an opportunity for updating our Visual Studio project setup, and start using Courier to alleviate some of the pains we were experiencing, when developing in teams and repeatedly deploying the site to test-servers.

In this post, I’ll start out by outlining some of the problems we were experiencing before, and in later posts I’ll follow up on these problems and try to explain, what we did to solve these problems.

The source of the problems

Most of the problems working with Umbraco in teams, stems from the fact that most central entities in an Umbraco project only exists in the Umbraco database. This means that to maintain a consistent development environment, developers either have to share the main Umbraco database, or they have to implement some kind of elaborate datbase setup, or perhaps use a third party package enabling coding your doctypes as classes.

The entities that recides in the Umbraco Database are:

• Document Types
• Media types
• Templates
• Macros
• Dictionary items
• Languages
• Datatypes
• Access rights
• Users
• Members
• Content
• Media

Of these Content and Media is special cases since it would perhaps be an odd CMS if it didn’t keep it’s content in some kind of database in order to make it possible to make it updatable and versionable. Templates (ASP.NET masterpages) is technically just kept as a record indicating that the template exist, the code itself lives in the filesystem, at least since Umbraco v4. Access rights isn’t actually kept in the database, but they’re based on the database record id’s, so there is a dependency on database data.

The problems with sharing the database

When developers share a database it causes at least two problems:

1. Developers can only work when working on a network with access to the network the database lives on. This might not be a huge problem in todays always connected reality. You could setup a server accessible on the internet, or use a VPN connection to the workplace network. But still a license for a SQL Server open on the internet, might be out of economic reach, and VPN access to a shared network and a company SQL server might not be feasible.
2. Developers might hesitate when setting up additional doctypes or other Umbraco entities. Working alone I would normally backup my database frequently, enabling a easy roll back by restoring the database and roll back in my CVS, if I discovered I was going in the wrong direction. This might be impossible to do if other developers is working on the Umbraco setup at the same time.

The problems with not sharing the database

On the other hand; not sharing the Umbraco database comes with its own problems:

1. Syncronizing Umbraco entities between databases. When a developer finishes his work on a feature, his code changes will be distributed through the CVS I presume his team is using. But there needs to be some kind of setup enabling sharing the necessary changes in the database between developers. This problem is analogous to the problem teams are experiencing when they need to roll out changes from development to staging and production environments.
2. It becomes difficult to determine what setup is the current “tip”, ie. what exact Umbraco setup corresponds to the tip of the code in the cvs?

Other issues

At Twins since our team consists of both, frontend, backend and in-between devs (me mostly), we use Visual Studio as editor and TFS as our CVS. (Us being a Microsoft partner might have something to do with it to). We also deliver more than 10 Umbraco solutions per year, which adds some specific needs to the mix:

• We’d like to be able to setup a new Umbraco project in Visual Studio fairly quickly without going through the usual online Umbraco setup guide.
• We’d like to be able to add developers and/or machines to a project without too much hazzle.
• We’d like to have as much of the project data in our CVS as possible.

What did we do?

What we did is going to be the subject for a series of blog posts I’m going to publish in the coming weeks (or, god forbid, months). My preliminary synopsis for the posts looks like this:

1. Designing a Visual Studio Umbraco project
   What is the optimal setup for an Umbraco Visual Studio project? How do we enable easy local development? How do we setup the project for deployment to staging and production servers? See part 1 about using web.config transforms
   See part 2 about MSBuild and Web application projects
2. Creating a new Umbraco project in Visual Studio using a Nuget Package
   We use a Nuget package for quick creation of Umbraco projects. This explains how we created the package, and made the package handle the MSBuild setup we arrived at in part 1.
3. Using Courier for Umbraco DB syncronizing
   How do we use Courier 2, to handle syncronization of the entities from the Umbraco database?
4. Handling Courier revisions
   This post should explain how we use the Nuget Package and MSBuild to setup some utilities for handling Courier revisions.