Drupal development & deployment

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
ryan_courtnage's picture
Posted by ryan_courtnage on August 23, 2007 at 11:02pm

I'm part of a tech startup who is basing our website off of Drupal 5.

We have a small team of developers who work on building the site simultaneously. We use subversion for code management. In previous (non drupal) environments , working together was easy: all the functionality, content, roles, etc were hard coded right into our code and template files.

With Drupal, we are struggling to find a way to all stay in sync. Primarily our difficulty is with content. Our static pages (ie: "About Us") fetch their content from the DB. If a change is made, there's nothing to commit to SVN, and other developers don't see the changes. Similarly, if someone adds a module, it's a manual process for other developers to enable and set permissions after 'svn update'ing.

We've yet to get to the point where we're pushing out to dev, test, and prod servers, but the same challenges will exist. Marketing wants to add something to a page. We'd want make the change locally, commit to svn, push to the test server, push to production. Problem is that part of that change is simply node content in the DB.

I've seen the ability to create ".profile" files - but that appears to only accommodate new installs, and not updates.

How do others handle development & deployment problems like this?

Categories: ,

Comments

Install profiles are for new

Posted by christefano on August 23, 2007 at 11:50pm
christefano's picture

Install profiles are for new installs, you're right, but you can write a module with a ".install" file with your database changes and run the update.php script to deploy them. This was just discussed on the dev mailing list:

At Advantage Labs, we find it quite handy to create a custom module for each project. Most Drupal developers probably do this anyway - for form_alter hooks, canned views, and other behavior overrides. We also log configuration changes in that module's .install file. There, we can put variable_set's, sql queries, node_type_save()'s, whatever we want.
...
At that point, for the process you're describing, we'd run update.php to bring in the config changes. Also, the developer can get a refreshed db dump that includes more of the production data and config changes.

There are also the DAST and AutoPilot projects, but I haven't had a chance to try them yet.

This was recently a topic in

Posted by add1sun on August 23, 2007 at 11:56pm
add1sun's picture

This was recently a topic in the developer mailing list. You may want to check out that thread: http://lists.drupal.org/pipermail/development/2007-August/025925.html. Also, spinning off of that thread Larry Garfield (Crell) has a blog post about his setup: http://www.garfieldtech.com/blog/drupal-dev-server.

Learn Drupal online at Drupalize.me

For what it's worth, we

Posted by eli on August 31, 2007 at 11:09pm
eli's picture

For what it's worth, we kinda half-assed it during initial development: putting as much as possible in modules and .install scripts. Changes to the database we generally tested locally, and then preformed again on the dev server. The dev server database was backed up hourly (just in case somebody breaks it) and I wrote a script to quickly copy the whole dev server DB to the local workstation (so that everybody could stay in sync).

We're a very small team, so it worked. With more than a few people, it gets tricky.

This was a hot topic at DrupalCampLA

Posted by Chris Charlton on September 10, 2007 at 6:40am
Chris Charlton's picture

A topic that needs a lot of documentation of best practices.

Chris Charlton, Author & Drupal Community Leader, Enterprise Level Consultant

I teach you how to build Drupal Themes http://tinyurl.com/theme-drupal and provide add-on software at http://xtnd.us