Drupal Source Control Strategy?

Question

In standard php or source code based projects we easily keep all of the code in SVN and each developer can checkout their own copy and collaborate on the same code.

When developing a Drupal site however, much of the work is in "setup". Besides the theme and modules you don't really have any "source code". How do you run multiple instances of the same site so developers can all work at the same time yet share their work?

Example Scenario:

We launch an initial version of a Drupal site with content type "X" created. We also initially launch a view on the site that lists all the nodes of type "X" in chronological order. The client starts using the site, add content, menu items etc.

The next release is planned to add user search ability to that view. The setup for that is contained in the database though. We can copy down the production database to our development version to get the latest data while we work on changing the view. During that time however the client can still be updating the site, making our dev database out of sync. When we are ready to push the new view to production, is there an easier way to do it other than manually repeat the steps to set it up on the production install?

Answer 1

You could save yourself some of the pain of configuring and working with SVN as described in Nick's article if you use the svn:externals property. This will keep your local version of Drupal up-to-date with the specified Drupal branch automatically, and you can use exactly the same mechanism for your modules. Additionally, because SVN will read the externals definitions from a file, you can put these under version control too!

I don't think CVS has an equivalent feature. However, it is quite easy to write a simple script that will automatically install a Drupal module, taking just a URL (I've done this for keeping my own Drupal site up to date).

As far as versioning the database is concerned, this is a much trickier problem to solve. I would suggest exporting a "stock" Drupal database to an SQL file and placing that under version control. Each developer would have their own local private database server to use. You could then provide a script that would revert a specified database to your stock version contained in the SQL file.

As an example of how this problem is solved in other ways, I'll describe the situation at work. I work on a web application; it doesn't use a database so doesn't suffer those problems. Our way of getting around the repeated setup of sites is to rebuild from source control and provide a program to achieve the automatic deployment of the sites. The program is used by our customers too as their way of creating sites.