Drupal version control using subversion and Acquia Dev Desktop

To really get the power out of Drupal and to create leading edge sites, I see that the best developers are also comfortable as PHP programmers.  They  want to create subthemes and they want to change PHP code as needed in the source tree.   This brings with it challenges as to how to do releases and what to do when a new version of drupal is released.
Here is the summary of a method of working I recomend to my clients that neatly solves the issues that come up:

  • Create (or re-use if you have one already) a Subversion code repository system that is accessible from both the production (and QA and DEV) LAMP stack servers as well as the developers workstations.  This will become the master code repository for your site
  • Developers install the Acquia dev desktop tool on their windows workstations.  This provides a fully self-contained stack that developers can use as they like.
  • Developers install the Tortois SVN GUI client for accessing (and later updating) the subversion repository.
  • Install the svn command line client on your production (and QA and DEV) servers.

The work steps on the LAMP servers are:

  • If you starting fresh, install the drupal core, modules and themes you use.  (You dont have to start fresh though, this methodology works fine for existing sites).
  • From the LAMP servers, perform an one time, initializing "svn import" of everything in the web root directory for the site into subversion.
  • Immediately after the import, perform a "svn checkout" on the LAMP servers.  This will add the critical ".svn" directories as needed within the tree and will later allow us to do incremental updates as they are commited to subversion.
  • Perform a full mysqldump of the site database, and make a compressed copy of it available on a windows shared drive.

Next steps are for developers:

  • Install the Acquia dev desktop control application and verifies it works before we make changes.  Stop the stack.
  • Install the Tortoise SVN GUI client and confirm that developers have access to the Subversion code repository.
  • Rename the acquia-drupal folder that will be found in the \Documents and Settings\<user name>\Sites folder to something like acquia-drupal-orig.
  • Using Tortois, perfrom a "SVN Checkout" of the whole project in to a new Sites\acquia-drupal folder.
  • Start acquia-drupal stack, and create your own mysql database locally matching your production site name
  • Import the database to the work station that was created on the server using the phpMyAdmin tool provided by acquia.
  • You should now have an exact clone of the production site - with database and source tree - and is completely local.

The developer starts work on making changes to the source tree:

  • They add directories for a new theme, modify php code and build CSS as they like.
  • They use tools they like (ex Firefox firebug, IE8, Chrome, whatever) and confirm everything works as they like
  • When done, they use Tortoise "SVN commit" to push just-the-changes they have made to Subversion.

 
On the LAMP stack, implementing these developer created changes is now a breeze:

  • Running "svn update" for the project now pulls down just-the-changes from the subversion server in to the tree.
  • If there is are any issues, it is easy to back out by just pulling down the prior version.

Good drupal systems are regularly updated for the core updates as well as changes to modules. 

  • Install the updated core and modules on the LAMP stack.  I always recomend creating unix patch file for applying drupal core changes, but this is not required. 
  • If all looks good, from the LAMP stack, perform a "SVN commit" which applies only-the-changes to subversion.
  • Create a matching database backup and make it available to the developers.
  • The developers use Tortoise "SVN update" to get the latest copy of production. 
  • I always advise my client developers to drop and re-import the database to ensue they are working with a matching copy.

We will cover these steps in more detail in following articles.  The beauty of this approach is that it can support multiple developers and it brings with it all the strengths of code versioning control used in Subversion.
 
If you need assistance in deploying this method in your shop, please contact me and I will be happy to help you.