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