We’ve moved into the next phase of our development. External users now have access to our testing server, and theylle be busy not only filing bugs but also creating editorial content. This means that we can’t just drop the database and recreate everything from scratch. (Darn!) However, we still need a way to make sure that:
- developers have a consistent environment for development and testing, so all changes need to be checked into the Subversion source code control system
- all significant changes are captured so that we can deploy the tested system on the production server
Here’s our current plan:
- Editorial changes (creating new nodes, editing existing nodes) happen on the testing server. Developers can test their local systems with real data by downloading a data dump from the testing server and loading it locally.
- Code changes that don’t require database updates can be pushed to the testing server after local testing.
- Code changes that require database changes or one-time administrative actions can be handled in modules’ .install files as modulename_update_somenumber() and _install() functions. This can be tested locally by loading a data dump from the testing server and then running update.php. It should also be tested from a fresh install. If the change works locally, then the testing server can be updated. (Make sure to run update.php on the testing server as well).
When we deploy the system to production, we’ll review all the content, remove the test data, and push the data and the code to the live site.
See http://heyrocker.com/drupal/content/deployment-and-change-management-problem for more analysis.
- 08 August 2008 at 4:08pm
- Drupal 5: Migrating a production database to a QA server | sacha chua :: enterprise 2.0 consultant, storyteller, geek
[...] on the configuration management strategy I described last time, I wrote some ...