Managing Multiple Drupal Environments and Version Control Tips and Best Practices

Managing Drupal development and deployment environments can get tricky… but it doesn’t have to be. Here are some quick tips for managing multiple Drupal environments.

The first rule is that code should always move one direction dev -> staging -> production. Content will move in the opposite direction during database syncs.

Before modules to export and manage configurations were around we actually had another rule content and drupal configurations always move the opposite way. This actually meant that when a developer finished something they would move it to production, then periodically the production database would be copied down and overwrite the staging and dev to make sure all the configuration and content in the database were always in sync. While things still aren't perfect, thankfully there are some modules and methods that can help with this process.


When Managing Multiple Environments You Want To:

  • Place environment specific settings in a settings.php file specific to the environment. We do this by having several config files such as and storing those in the VCS and then just creating a symlink to the appropriate one on each environment. We force variable values in these such as Environment Indicator settings, solr connection information and other information that we want to avoid having to reset if we get a new copy of a database from production. Using modules like will even let you enable and disable modules per environment, such as devel / varnish / memcache etc. Another method exists where you can use a single settings.php file and include conditionals that are based on either the IP address of the server or the hostname, and set environment settings based on them.
  • Keep track of configurations that change in dev so they can be recreated on other servers. This is where modules like configuration management, features, and exportables com into play. They enable us to export some sort of code to represent the change and place it into the VCS, by doing so configurations are no longer tied to the database and can move upstream just as all other code does.
  • Periodically make sure all environments are in sync. This is best to do after code has been pushed and there is no development currently going on that involves lots of configurations. Copy the database from production to all other environments, if you were able to store environment specific settings in settings.php these step becomes easy. If there is some sort of ongoing development you can export those settings and re-import them after. If module updates are in the codebase, for dev but had not made it to production be sure to run update.php with your new database. It is safer to just try to avoid the last situation, and wait until after the updates are pushed through to sync.
  • Use rsync to get the latest files from the production server after getting a new database, the files directory should not be in VCS so you need to grab the files that it references.


Working with Multiple Development Branches

  • Working with feature branches is a good thing when doing parallel development, as it makes merging and testing one feature at a time easier. If possible updating your feature branch with trunk updates that are made can make merging and testing when complete easier.
  • Each branch should have its own database, so much of what makes a drupal site is stored in the database, that switching branches on a single database can lead to issues. In the real world though you may need to push a quick fix and want to do some quick work on another branch. In this case these are the areas to really watch out for, some development module updates for example update database schemas, each branch may be expecting a different schema and cause issues. File structures can also change and drupal may be looking for files in a non existent location. If all changes are code based, switching branches is fine, changes that occur in the database should be avoided. Items like update views should not affect you but you should keep in mind that you are effectively developing against a different branches database so while your change may work there, it might not work on the correct target branch.
  • Just as we put settings for the specific environments earlier we can do the same with branches, and set database connection strings in a branch specific settings.php file, that way one can merge / update a branch codebase and not have to worry about then going and re-pointing the database.
  • While sharing a database is a bad idea, I almost always share my files directory, Just create on files directory in development and you can symlink if from all the different branches.


General Tips for Maintaining Multiple Drupal Environments

  • Smaller changes and commits and feature branches are easier to manage, committing and merging frequently with the development of others helps avoid conflicts. Also pushing and syncing configuration settings using something like configuration management is far easier to keep track of changes an import updates. When these grow or go long periods without updates it takes much longer to be sure that there are no conflicts between developers, and lots of manual checking might be needed. With small changes a simple glance at what is being updated is probably enough.
  • Pushing smaller updates upstream is also generally easier and requires lest testing, . as As piles of updates build for production, the list of testing grows to.
  • Get in sync after code pushes, with smaller, frequent updates. getting Getting a new database from production is usually not a hassle as there should not be much development for it to interfere with.
  • Back up your databases, before updates and merges, and importing configurations. It is far easier to restore a database than to try to fix issues in mysql, or to have to recreate something like a view from scratch.


Get Help Unleashing Drupal’s Potential

If you’re looking for help customizing your Drupal site to best work with your company or organizations processes or if you have any further questions about maintaining multiple Drupal environments, contact us today.