Drupal & Subversion Workflow Strategy

Ignore These Files

Commit the entire Drupal installation, except the following folders/files:

  1. /.htaccess (top level)
  2. /sites/default/settings.php
  3. /sites/default/files (the "files" directory, wherever it's located.)

.htaccess

This file is most likely server specific and may be tweaked for production differently that dev. E.g. the public dev server has password protection set in this file.

settings.php

This file is going to contain at least database specific information and if committed to repo, would mess with other dev copies, namely their database connections. This is the minimum conflict that could occur if this file was versioned.

files

This is arguable, but I say no for a couple of reasons. Contents herein are going to be mostly updated by users. Users are not going to be committing their changes. Also there are many automatic files generated here by Drupal which have no need of versioning. Lastly, omitting this folder will keep the size of the repo down; this may be a consideration when repo size = more money.

The contents of this folder will be synchronized, or rather downloaded from the production site to all devs via FTP.

Dev Workflow

Updates to Local

When a developer is going to start a new iteration, here is the basic workflow to match his/her environment.

  1. Log in to production site and download the database using Backup & Migrate.
  2. Update local database with the snapshot from the previous step.
  3. Connect via ftp to the production files directory and download anything new (one-way, remote to local synchronization.)
  4. Perform a repository update to the local working copy.
  5. Ready to code!

 

Updates to Production

When a developer is finished with the iteration, here is the workflow to get the changes into production.

  1. Duplicate any necessary database changes directly on the production site, either through the Drupal UI, or via hook_update (modules only), or direct sql code.
  2. (optional) Take production site offline if needed.
  3. FTP anything that needs to be in the files directory (probably never happens).
  4. Perform a repository check in of local code, carefully noting the changes made in the check-in message.
  5. Perform a repository update to the production working copy.
  6. Ping /update.php, if needed.
  7. Test as needed.
  8. Bring site back online (if offline).

 

Further Reading

http://ceardach.com/blog/2008/06/development-environment-drupal