Pantheon Community

Deploying dev-environment database changes

Hi! I’m working in the Pantheon system for the first time and was wondering what the best practice is for handling database changes in the Dev environment. I understand the Pantheon Workflow:

But what about when Dev work involves database changes? Perhaps I create a new menu for a new section of the site I’m building out. Or I need to install a new plugin to help with a new feature I’m working on. In these cases the plugin/menu creates database entries on the Dev environment which need to make it to Test/Live.

If I follow the Pantheon Workflow to merge Dev Code and Live Content in the Test environment, my Dev database changes are missing. I end up with half-installed plugins which have their files but not their data. Do I need to manually make database-related changes (install plugins, update menus) on the Test and Live environments? If so, is this before or after merging the Dev Code? What’s the best practice for merging these types of changes efficiently with a minimal risk of errors?



Hi Andrew,

I’m going to answer from a Drupal 7 perspective, since that’s the platform I use, but I think that the same general principles apply in WordPress. Things have changed a lot in Drupal 8+ with the Configuration Management system, but I’m not sure that there’s a parallel to that in WP, so I’ll avoid talking about that.

In general, your choices are:

1. Manually repeat the database changes in each environment as you deploy up the chain toward LIVE

I’m not sure about in WordPress, but if you add the code for a new Drupal module that includes database changes during installation in the DEV environment, and then deploy that code to the TEST environment with the database from the LIVE environment, Drupal will automatically want to re-run those database changes when you check for pending database updates.

Other types of operations that might require manually “replaying” database updates in a higher environment as you suggested would be any site configuration change that modifies the database. In Drupal, common examples would be adding a new page type, adding or editing Views, or adding or manipulating the order of some menu items.

Obviously this approach works, and is easy to understand, but has the disadvantage of being prone to human error as the database changes as manually repeated in each environment. There is also a necessary delay between the deployment of the code and the database changes that can only be as short as your fastest human can manipulate the site’s admin UI.

2. Automate database changes in code so that you can actually “deploy” the database changes in a repeatable way in each environment.

There’s a Drupal-ism called an “update hook” that allows you to write code that can automate tasks that you want performed during a deployment. This can include things like enabling new modules, adding new menu items, etc.

Broadly speaking, this approach fits in with a philosophy of capturing as much of your site’s configuration in code, and making deployment operations repeatable. For further reading on this, I would recommend the Dcycle Manifesto, in particular the section titled “Incremental deployment must be standardized and repeatable.” Again, the tools for this in WP would be different (e.g. “WP-CFM” for WordPress instead of “Features” for Drupal 7), but I think the concepts are largely transferable since both platforms share the complication of both content and configuration being stored in the SQL database.

@ataylorme is a very smart cookie who works at Pantheon and wrote a series of blog posts on configuration management in 2016, including one whole post about managing site configuration in code in WordPress.

I hope that helps and has not confused matters further. In general, I think this approach cuts against the grain of how many Drupal and WordPress developers are used to working, and it can be a bit more time consuming, but it pays huge dividends over time to treat your site configurations as code rather than database changes by giving you an increased sense of control, repeatability, confidence in your deployments, and the ability to have other developers review changes before they are deployed.

Good luck!