[development] The right way to manage Drupal webiste development

[Allie Micka]

> Michel Levy-Provençal wrote:

>> 2/ When our sites will be online, we will need to continue the
>> development. The only way we found to manage this is to lock param
>> tables on the live instance. And when we'll want to update the live
>> website, we'll have to :
>>  - update the php code (thanks svn)
>>  - and (this is quite touchy) update the param tables using a sql  
>> import....

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.

Deployment means:
   A. committing the SVN changes (and updating the instance, if  
necessary)
   B. running update.php

This is certainly more time-intensive, but it pays off if you have  
concurrent development and/or any sort of staging/QA process.  You  
can consistently QA and commit independent changes

FWIW, we (and all other Advantage Labs Drupal hosting customers) also  
use a custom SVN process for Drupal management, where each commit by  
a developer results in 3 steps:

   1. A pre-commit hook that "svn commit"'s the production site's  
data (for file uploads, database, etc. changes)
   2. The actual commit by the developer, provided step #1 results in  
no merge errors.
   3. An "svn update" on the production server instance to sync up to  
the developer's changes.

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.






Allie Micka
pajunas interactive, inc.
http://www.pajunas.com

scalable web hosting and open source strategies