Managing the whole chain: Dev - Integration - Staging - Production is a major issue for Drupal. It's one of the Drupalcon2007 conclusion. As we discussed during the Building High Traffic and Scalable Businesses with Drupal , it is imperative for us to have migration methods and tools.
At France24, we are massively switching on Drupal. At the end of the year, france24.com website and several satelites will be using Drupal 5.2. We need a simple architecture to allow our team of 5 developers :
- to work on the same code repository and database.
- test the function on an integration environment
- publish content and edit configuration on a staging environment
- easily migrate on production or "synchronise" with a production environment.
Today, a majority of the Drupal dev i asked this question aswer me : "we are working directly on the production server, reporting manually the configurations we've made on a staging environment..."
At France24 we worked during 2 months to find a simple solution to answer this question. We have mounted a complete dev -> integration -> production environment responding to our needs. For some days, this platform is used by our team. It seems to work correctly, but we are still testing it. If you want to join the experiment and share, you are welcome.
So here's is our solution.
We have based the synchronisation mechanism on:
- MySQL Replication
- Even & Odd Database Identifiers
Each developer has his own PHP / DB environement for dev and testing purpose. All the php code is commited by the different developpers on a central SVN and continuously updated on an integration platform. Every modification of the configuration (blocks, menus, views, ...) are made on the integration platform (in the integration DB) using the Drupal GUI. We have created a special module that hacks the DB accesss : every records created on the integration DB have odd ids. At the same time, the production website is using his own DB. The DB access module we have created generates even ids on the production DB. Using this method the production website can permanently feed the integration platform.
For this, we use a MySQL synchronisation from production to integration. The other way is blocked. By using even and odds ids we are sure to avoid records conflicts.
Each time we make a new release of a web site we dump the integration db, make a new folder with the new php code, create a new setting.php that reference the new db, test it for a short moment on a specific virtualhost on the production platform , and if every thing is ok, change the www alias of our webserver so that it links to the new version of the website.
Using this method :
- we have a staging platform that is tested permanently (the integration platform)
- the switching period is quite short (changing an alias)
- we can roll back very easily by changing the www alias of our website
- we make a backup of the integration db 2 times a day, so that we can roll back in case of an unresolved blank page bug... :)
Michel Lévy-Provencal: Internet Technical Manager (firstname.lastname@example.org)
Corentin Delorme: Drupal Developper
Elbou Elbechir: Drupal Developper
Luc Mombrand: Drupal Developper
If you need more technicla informations on the solution or wanna share ideas, you can contact us by email.