Home / Comment permalink

Drupal 8 Configuration Workflows using Git

This blog post is a textual representation of the video shared yesterday. If you are visual learner, watch it. If you are in a hurry, read this blog :). Peter's video also shows how configuration_log module can be used to materialize all config changes in Prod so they may be easily integrated back into the codebase. That is not covered here.

The following commands are our current best thoughts on how folks will move configuration across environments using Git and the Drush config commands. Our goal is to coalesce the community on a best practice that non-trivial Drupal sites will follow.

# Save an arbitrary configuration change using Drush. Using the admin ui would work just as well.
local$ drush config-edit system.site

# Export all your active configuration to a directory labelled 'vcs'.
# This is a 3rd $config_directories[] item specified in settings.php (see below).
local$ drush config-export vcs
local$ git status

# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
# modified:   ../config_vcs/system.site.yml

# Commit config changes so other devs can see them, and so we can propagate to other environments.
local$ git commit -am "New site information configuration"

# Push your changes. Resolve git conflicts as usual.
local$ git push

# Now, on the dev server, get latest codebase
local$ ssh -A me@dev.server.example.com

#   Welcome to dev.server.example.com.
#   Last login: Wed Feb 26 19:43:14 2014 from localhost

dev$ cd www/docroot
dev$ git pull

# Import new config
dev$ drush config-import vcs --preview=diff

# Run DB updates, as usual
dev$ drush updatedb

In terms of the settings.php we have an array of config directories:

['active'] = 'sites/default/files/config_JeZmqqMqX_S80W7DKVKKMT7uH8iJIeUHkuTWks8b3ZU/active';
$config_directories['staging'] = 'sites/default/files/config_JeZmqqMqX_S80W7DKVKKMT7uH8iJIeUHkuTWks8b3ZU/staging';
$config_directories['vcs'] = '../config_vcs';

The third entry gives us the "vcs" name that is used with the Drush commands. This key is arbitrary, as is the path. Acquia Cloud will use a directory named 'config_vcs' at the root of the site's Git repository.


Posted on by kim.pepper.

Thanks Moshe. That looks like a pretty simple workflow.

Now we just need to deal with git merge conflicts. ;-)


Posted on by sun. (not verified).

The purpose of introducing the 'staging' directory was pretty much exactly this.

What prevented you from using 'staging'?

Posted on by mweitzman.

Thats true, this technique would work fine by tracking the staging dir in Git directly. We decided not to do that for Acquia Cloud because we think some customers will use a mix of techniques. That is, customers can use both a Git workflow and a "copy my yml files to staging and them import" technique. When both of these are in use, it is possible to overwrite the other person's work and then and the wrong stuff gets imported. So we are thinking to leave the Drupal UI alone as the "owner" of the staging dir. Perhaps we will revise this decision in the future since folks are confused about the 3rd config dir.

Posted on by Rob Bayliss (not verified).

Nice article. I'm curious if you have any recommendations for dealing with the staging directory? Using the method above, active would be reverted to what's in the vcs directory, but your staging would still be out of sync.

Posted on by Christian Lopez.

Why is the third folder needed? I thought having staging config folder under source control was enough.

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.