Managing configuration settings such as user permissions and system variables is very critical in any web application. In Drupal environments we use these two mechanisms to version those settings and replicate changes automatically across different environments:
Drupal features
Features is a Drupal module that offers the following benefits:
- Allow saving settings in code and keeping track of changes.
- Allow automation of the deployment of those setting changes to different environments.
- Flag affected settings in the system.
- Allow reviewing changes in settings that don’t match with the ones saved in code.
For instance, say that you created a new content type in your local environment, and developed a new section with views, panels, and other details related to that content type. The features module allows you to select and save all those settings – which are stored in your local database – in code (basically a module), and hence include those changes in your git repository. Then, when you deploy that code to a different environment, you just need to enable that feature (module) to apply those changes to that other environment – which basically take all those variables from the code and store them in the database of that environment.
Another cool thing about Drupal features is that if any of those settings is affected in production, you will be able to compare what is in the database with what is in code, and decide if those changes need to be reverted, or saved in the code as a new version.
Update rules
Update rules are particularly helpful to automate deployments to other environments. They allow you to:
- Revert Drupal features and make changes to settings, content types, variables, views, panels, etc.
- Enable / disable Drupal modules automatically.
- Execute custom queries in the new system to automate changes to the data.
Those rules have incremental IDs associated to them. That allows Drupal determine what rules are pending to be executed. Say that you have an old backup of your system, and want to rehearse the deployment of a new release. When database updates are executed (drush updb), Drupal will determine what was the last update rule that was executed and will then execute the pending ones in the order they were specified, avoiding manual processes.
Finally, in order to ensure that those features and update rules are executed properly in any rehearsal of a deployment during the testing process, it’s recommended to remove completely the database you have in the testing environment and import a fresh database dump from production to see how those updates affect the real data. Failing to delete the testing database before importing the dump from production could lead to misleading scenarios, because not all variables in the testing server are removed during that process. The command I use to rehearse deployments is:
drush sql-drop -y && drush sql-query --file=<db_dump_from_production> && drush updb -y
