Another idea we had today about this question... This is a chalkboard solution. An idea... Something that has to be simplified and tested. We gonna continue the reflexion and try to implement the solution we have found after... If somebody has any idea to simplify the process, you are welcome... _______________________________________________________________________ Imagine we have 3 instances: - Production site - Staging site - Integration site All the php code is commited by the different developpers on the Integration site. Every modification of the configuration (blocks, menus, views, ...) are made on the integration server using the Drupal GUI. For each version of the site, we use a special ID suffix for each record in the database. In the folowing example : - the Production website is in V0 and the Production DB is using 0000xxxxxx ids. - the Integration website is in V1 and the Integration DB is using 0001xxxxxx ids. while(0) { 1st Step: "Production to Staging synchro": The Staging DB is configured to be a slave of the Production DB to allow a synchronisation Production->Staging. 2nd step: "Integration to Staging synchro": We transfer the Integration php code to the Staging website. We change the configuration of the Staging DB: the Staging DB is now configured to be the slave of the Integration DB to allow a synchronisation Integration->Staging. Using suffixed ids allow us to limit conflicts between Integration and Production. At this step each new element "created" in the Integration cannot conflict with the elements from the Production. 3rd Step: "Staging period" The Staging DB is configured (another time) as slave of the Production DB. This allow us to tests the Staging as a real-time replication of the Production with the specific functions of the Integration. PROBLEM: At this step each update done on the Integration is lost.... The Production overides it. Only created elements are saved... (And this has to be fixed!!!!) 4rd Step: "Go Live!" When the website is correctly tested, we stop the Production website, dump the staging and transfer code and datas from Staging to Production. 5th Step and last step: "Update Integration Website" We transfer code and datas from Production to Integration. } 2007/8/17, Allie Micka <allie@pajunas.com>:
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
-- Michel Lévy-Provençal +336 23 93 60 16 | mikiane.com