Managing Drupal Development with Multiple Developers - Jay Kalpathy


Published on

What are the challenges in managing a Drupal development cycle with multiple developers?

So you've decided on Drupal and are putting a development process in place. Source code control - check, build/release process - check. And then you hit the database. Do you use install profiles? Do you just apply the changes each time? I'll talk about some of the Drupal specific problems we faced, especially synchronizing database changes, options we considered and how we overcame the challenges. Our site is

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Managing Drupal Development with Multiple Developers - Jay Kalpathy

  1. 1. Managing Drupal Development with Multiple Developers Jay Kalpathy NetLine Corporation
  2. 2. Who are we? <ul><li>B2B lead generation & advertising network </li></ul><ul><li>Over 15,000 partners in our network </li></ul><ul><li> is our Drupal based partner portal </li></ul>
  3. 3. The Scenario
  4. 4. Useful Tools <ul><li>Version Control (modules, themes): </li></ul><ul><ul><li>Subversion , CVS, Git, Bazaar </li></ul></ul><ul><li>Virtual Machine: </li></ul><ul><ul><li>VMware, Xen , … </li></ul></ul><ul><li>Build Automation: </li></ul><ul><ul><li>Make , Ant, Maven, … </li></ul></ul><ul><li>Test: </li></ul><ul><ul><li>Selenium , Drupal SimpleTest module </li></ul></ul><ul><li>Not Drupal specific. Use what you’re familiar with. </li></ul>
  5. 5. What about the database? Enable Module, Blocks, Permissions, Module Configuration
  6. 6. Database Issues <ul><li>Database changes have to be redone on each server </li></ul><ul><li>Content team has to work on the live site </li></ul><ul><li>No good way to manage the database changes under source control </li></ul>
  7. 7. Solutions <ul><li>Manual – make the changes each time ! </li></ul><ul><li>Shared database / shared codebase </li></ul><ul><li>Shared database / separate codebases – Chapter Three </li></ul><ul><li>Install profiles </li></ul><ul><li>Dave Cohen: Reserve 1000 id’s for Staging </li></ul><ul><li>France24: Odd / Even id’s </li></ul>
  8. 8. Shared Database <ul><li>All developers work remotely, on the same server, with ONE database .   Each developer gets access to their own codebase and files are managed via repository. … We keep the practice of “ code goes up, data comes down ” … Jen Lampton, ChapterThree </li></ul><ul><li>Sharing a DB works well, but D6 has introduced a few annoyances . For example, when our themer is adding templates, the registry picks it up, and produces errors for everyone else, until we get the template. A good work around has been for the themer to commit an un-modifed template, so that everyone else can at least keep running. As for dealing with dev/staging/live servers, as Jen mentioned, we keep the DB coming back down from the live server, to staging, to dev. All DB changes that need to go the other way are either handled by install file updates, or documented and manually applied . This is really the only way to guarantee that the live DB stays valid. I wouldn't trust an automated system to touch our live DBs . … ~Rob @ ChapterThree </li></ul>
  9. 9. France24: Drupal Staging <ul><li>Force the staging server to create only even numbered ids and the live server only odd numbered ids . </li></ul><ul><li>Use MySQL synchronization from production to staging </li></ul><ul><li>Flip from production to staging to go live. </li></ul><ul><li>Drupal 5: Sequences table, auto-increment’s </li></ul><ul><li>Drupal 6: No more sequences table. </li></ul><ul><li>Is France24’s Stage module released? </li></ul>
  10. 10. Other Solutions <ul><li>Deployment - The deployment framework is a series of modules which are designed to allow developers to easily stage Drupal data from one site to another. Unfortunately, all the modifications have to be done manually, so on a large production site it can be very difficult to keep the stage site up-to-date with user content </li></ul><ul><li>Staging - Description is vague since it is a new comer to this arena. Appears to be designed to send staging configuration to the production site. Could potentially write over user created content. </li></ul><ul><li>AutoPilot - AutoPilot is a complete build system that captures code and configuration changes from entire teams of developers, merges and synchronizes it, and provides a framework for easy, consistent, and optionally, scheduled builds. Not developed for Drupal 6.x </li></ul><ul><li>Stage - The stage module taps into Drupal's revision system to allow host-based staging of content stored in the database. No module is available and appears to be abandoned. </li></ul>
  11. 11. Conclusions <ul><li>It is a pretty hairy problem, but … </li></ul><ul><li>A shared database, coupled with mirroring production data to staging & dev – simple solution, but solves 90% of the problems. </li></ul><ul><li>If you really need it, the France24 solution is very elegant, but be prepared to get your hands dirty. You’re making edits to core. </li></ul>
  12. 12. References <ul><li>BDUG Thread: </li></ul><ul><li>France24: </li></ul><ul><ul><li>Original post on </li></ul></ul><ul><ul><li>Good explanation by CodeBaboon: </li></ul></ul><ul><li>Dave Cohen: </li></ul><ul><li>Shaun Haber’s presentation from BADCamp 2008 </li></ul><ul><li>Greg Dunlap on the Deploy module: </li></ul><ul><li>Questions?? </li></ul>