Your Drupal site is built to the bestest of best practices. It’s fast, responsive, secure, keyboard-friendly, touch-friendly, pet-friendly and downright gorgeous. So what’s the problem? All’s well and good until it comes time to deploy all the work on that hot new landing page and the developers suddenly balk.
There is an unspoken blocker. Apparently, the developers were operating under the assumption that the new landing page would never have to leave the development site. Next, they return with a whole new estimate with a revised timeline to manually rekey the configuration and content directly on the production site, including a provision to triple-check their double-checking. People inevitably make mistakes; humans are not robots, you see?
So why the surprise?
Before we can answer that question, a little background is necessary. Drupal has become so successful as a CMS because it provides an incredibly powerful administrative user interface for making structural and configuration changes, so-called “site building”. This work is stored in the database right alongside content. In Drupal 8, this is called “active” configuration.
WordPress developers will often copy an entire database plugin table from a development site to a production site. This practice does not work for Drupal, since Drupal modules follow well-established best practices for relational databases. The information is often spread across multiple tables and is rarely modified directly by developers. Instead, it is accessed via user interfaces and application programming interfaces (API). The good news is that Drupal developers can automate these changes without having to dig into database tables.
Don't Manually Rekey, Automate!
All of these configuration changes can be exported out of the database, tracked, and transferred from one environment to another with version control. This capability (Configuration Synchronization) is built right into Drupal 8 core and is one of the greatest reasons to upgrade from previous versions. Yay!
Version-controlled deployments can also be accomplished in Drupal 7. In order to be successful, especially over the long-term, they require an additional layer of strategic planning, coordination, and discipline. There are several ingredients to this process, but key among them is the contributed (and retrospectively misnamed), Features module.
At Isovera, we refined an approach in Drupal 7 that emulates Drupal 8 with a single canonical Featuresmodule named
site_config. But we still inherit client sites that have scattershot or ad hoc configuration modules. These collections are often numerous and undocumented with incomplete coverage of the site, and fall into disuse and neglect. Drupal empowers site administrators and contract developers to be able to make configuration changes directly on the live site. But these changes come at a cost. The disconnect with configuration captured in version control grows worse. We do not want to lose these changes and introduce regressions, but we also have new work to deploy. Hence, our deployment dilemma.
An Ounce of Prevention
Fortunately, the immediate solution is simple: update the configuration in version control to match the production site. This step is a given during active project development. It is only in the months and years after launch that it becomes disregarded. Instead, it should be a part of a routine maintenance plan.
Instead of waiting until the new landing page gets underway, be proactive and audit your configuration today. At Isovera, before taking on a new client project, we perform a standardized site audit. A quick check reveals any overrides and or inconsistent coverage. On a Drupal 7 site, additional time may be necessary to organize and streamline the relevant Features modules. In any case, a little preparation before a redesign or new feature launch goes a long way.