Stop Using Drupal 8 Features on Production!

Mike Crittenden, Software Architect
#Content Management | Posted

In the Drupal 7 days, it was pretty common for a production deployment to include the (in)famous “drush fra” line to bring in any new/updated config. Because of that, lots of former Drupal 7 developers are bringing that practice to Drupal 8. But things have changed, and this is generally a bad idea in D8.

Why shouldn’t I use Features on Production in Drupal 8?

When deploying from QA to Prod, you have tested the full site config on the QA environment (right?) and you want to mirror that onto Prod. Running drush features-import-all only handles the config that is Featurized, and a site typically contains a lot of config that you don’t have in a Feature.

Because of that, just doing drush features-import-all doesn’t ensure that Prod is a mirror of QA, thus you can have bugs/regressions/etc.

Ok, then how do I push config to the Production site?

Instead of using Features, you’ll want to do a full configuration export from the QA site (i.e., the site that has the exact configuration that you want to push to production and has been pre-release tested) to the production site.

Modify your settings.php to set the location of your config/sync folder and add that folder to your git repository. On Stage/QA, use drush config-export to export the site config and commit/push the config to git. On Production, pull from git, then use drush config-import to import the full configuration.

But what about pushing config to other sites, like Local/Dev/QA?

To update config on any non-production sites, it’s fine to use Features. Make sure all configuration is packaged into Features modules, then run drush features-import on each module that you’d like to import.

Note that drush features-import-all is supported but not recommended. It’s better to import config only from the specific modules that you care about.

What about update hooks?

It’s sometimes a good idea to write an update hook to import your configuration, so that other developers or automated builds can pull in updated config without having to import ALL Features. The Features module includes a helper function to import/revert your custom module. However, always be sure to test module_exists(“features”) before calling this since not every environment might have Features enabled.

Why even use Features at all if it can’t be used everywhere?

What’s the point of using Features if it can’t be used in Production? Why not just use config-export and config-import on ALL environments and take Features out of the picture?

Core configuration management allows you to synchronize the full configuration between two sites. While it is important to have QA and Production be synchronized, you rarely want to fully synchronize your local Development environment with QA or Prod. Often your local Dev has many configuration settings that you wouldn’t want to export, or wouldn’t want to be overwritten or lost by importing another site’s config.

Features is intended to organized related configuration, and to help build reusable functionality. It isolates development changes to custom modules, allowing multiple developers to merge their work more seamlessly.

Rule of Thumb:

Use config-export and config-import when you want two sites to be identical. Use Features for all other cases.

What about config that needs to be different on each environment?

For example, say you have a piece of config on staging that needs to slightly different than production. You wouldn’t want to do a full config export to production since it would overwrite that value.

In a case like that, perhaps use per-environment settings.php to set that config, or maybe look at using the State API for that piece of config.

The config-export command also has an option for excluding certain configuration that you might not want to export/import.

Are there cases where you DO want to use Features in Production?

It’s possible. One example is the use-case of multi-site where you might have dozens of different site configs and can more easily manage that with different features on the site rather than using config-export and config-import.

Where can I find more info about this?

Here are some links:

Mike Crittenden

Mike Crittenden

Software Architect