Moving Your Drupal 8 Configuration from Local to Server and Back

Update: a textual representation of the first half of this video has been posted.

Two weeks ago I had a great opportunity to spend a few days working with Moshe Weitzman (moshe weitzman), Justin Randell (beejeebus), Alex Bronstein (effulgentsia), and Stéphane Corlosquet (scor) to look at the challenges and best practices for using the new Drupal 8 configuration system (a.k.a. CMI) to move changes between a local development environment and one or more server environments. We developed ideas, considered new modules for Drupal 8, and tried to figure out if there were any changes to Drupal 8 core that would be needed to make the system better for developers.

One outcome of this was two new modules Configuration log and Configuration Read-only mode. These were written to help demonstrate the capabilities of the new configuration system and enabled us to implement key elements of possible new configuration staging and management workflows. An additional outcome was a number of enhancements by Moshe to the latest version of Drush to facilitate the import and export of configuration.

The screencast video below walks through the process of moving configuration from a local development version of a site, up to a development environment on a server and then to a "live" environment using Acquia Cloud Free. The "live" environment was detected in settings.php and that logic triggered the Configuration Read-only mode module to prevent any configuration changes in the administrative forms. We also used a Cloud Hook to automatically import new configuration when a new git tag was deployed to the "live" environment.

The video also shows the reverse process of bringing a configuration change back to a local codebase. For that we used the Configuration log module and committed each configuration change into a "recorder" branch in a git repository that was a clone of the site codebase. By creating the "recorder" branch from the same git commit as the deployed site is running, it's possible to use native git operations to merge the configuration changes back into the local clone of the codebase, as shown.

While we were happy with what we are able to demo, the experience convinced everyone involved that keeping the active configuration in files was more difficult in terms of development workflow, and led us to push for the proposed Drupal core change to keep the active configuration in the database.

We also discovered a core bug that mean a small subset of configuration imports did not work - so we had to patch around it for the demo and file an issue. The good news is that the bug has already been fixed thanks to Tim Plunkett.

Comments

Posted on by Yves Chedemois.

configuration_log.module looks like a powerful tool, since many issues config sync are hitting are caused by the "squash a series of sequential changes and deploy them all at once, losing ordering but hoping for the best" principle.

The blog post and video are a bit fast on how your setup leverages the module though. Care to expand a bit ?

Posted on by Peter Wolanin.

There is a very crude drush command included with the configuration_log module that I used for the demo - basically that was just running in a loop.

The git repo with the recorder branch was under the home directory of the cloud site user, hence I could just pull from it using ssh.

For a robust solution, we'll need to build up e.g. a module or script that creates a new recorder branch when a configuration import happens, and build better daemon or queue and queue-processing code

Posted on by Yves Chedemois.

Oh, OK. That drush command doesn't seem to be in the git repo for configuration_log yet :-)

Posted on by Peter Wolanin.

Oops - sorry "Your branch is ahead of 'origin/8.x-1.x' by 1 commit."

Pushed it now.

Posted on by Peter Wolanin.

Moshe also posted some more of the technical details at https://www.ac quia.com/blog/drupal-8-configuration-workflows-using-git

Add new comment

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.

Filtered HTML

  • Use [acphone_sales], [acphone_sales_text], [acphone_support], [acphone_international], [acphone_devcloud], [acphone_extra1] and [acphone_extra2] as placeholders for Acquia phone numbers. Add class "acquia-phones-link" to wrapper element to make number a link.
  • To post pieces of code, surround them with <code>...</code> tags. For PHP code, you can use <?php ... ?>, which will also colour it based on syntax.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <h4> <h5> <h2> <img>
  • Lines and paragraphs break automatically.
By submitting this form, you accept the Mollom privacy policy.