What is the suggested workflow for migrating configuration from dev -> stage -> production

Hey, I recommend @heyrocker's cmi session from Portland, he mentioned you can control which directory is staging and which is your active via configuration. On dev site you use the default but on live site you switch them. So active store is in git, when you deploy to prod, the active store on dev is staging store and then you just sync changes from the ui or with drush

I've tried to watch the video though the it is very hard to try and figure out what is on the slide with the deployment structure (are the slides up anywhere?) :) But one question that came out of our camp (and which I was unable to find a clear answer on even after watching the video) was: while figuring out a deployment workflow from one server to the next was complex but doable, what is the suggested workflow from multiple local environments (ie multiple developers) into dev (or between each other) - I would imagine every team member would be sharing the same or similar environment so how do changes on one teammate's machine come over?

This doesn't quite answer your question, but it does describe a more simplified git config import workflow: #1831818: Document git config import workflow.

The details of more complicated workflows are still being discussed.

I'm also very interested in the recommended workflow for local development.

If the recommended method of using it on a live environment is by swapping the folders, then it feels a bit hacky and it doesn't seem to solve the problem of having multiple local environments.

The actual settings file has this comment.

<?php
/*
 *   $config_directories = array(
 *     CONFIG_ACTIVE_DIRECTORY => array(
 *       'path' => '/some/directory/outside/webroot',
 *       'absolute' => TRUE,
 *     ),
 *     CONFIG_STAGING_DIRECTORY => array(
 *       'path' => '/another/directory/outside/webroot',
 *       'absolute' => TRUE,
 *     ),
 *   );
*/
?>

I'm following back on this issue. I posted the question on stackexchange after @chx posted to ask questions there. I asked the question at http://drupal.stackexchange.com/questions/85635/what-is-the-suggested-wo... and the response from @berdir is pleasantly surprising:

After talking a bit with CMI maintainers, the discussion on what's the best approach isn't finished but the following is what makes the most sense at the moment.

Trying to keep it terse for now, will try to expand based on questions/when the referenced issue is resolved with an official answer.

So, first, the facts...

• As already mentioned, there's the active and staging directory. Active is fully managed by Drupal, making changes directly in there (direct or indirect by switching to a different location) is not supported.
  Staging is where Drupal looks for configuration to import and doe otherwise not care about it.
• The import process is important, configuration changes can affect a site in a certain way and needs to be checked for validity. You can't change the field type of a text field to an entity reference, for example, that just doesn't work.
• The config import always needs to run on all configuration, you can't import a single view or node type. It was tried, but trying to cope with dependencies, removes/renames and so on resulted in an very complicated system and it didn't work.
• The only way to re-install default configuration, is to re-install that module. Which means that it would first try to remove all configuration (like fields). So that's not really an option. Manual, specific changes in update functions are possible but too tedious for this I think.
• As the features module describes, it will be focused on providing re-usable functionality, not continuous deployments of configuration. This is what it was designed for in the first place.

Given that, the recommendation right now is to put the staging directory into version control. Each developer has then full control over what he puts there, either by copying the whole active directory over, or just a specific configuration file. The staging directory changes are then committed, pushed to production and the configuration import is run (in the UI or with drush).

So from the looks of it, it does not seem like we have to have the cross-linked active/staging strategy anymore; everything goes through the import system (be it the ui or drush) which certainly helps simplify the tasks. Followup questions from me are going to be:

• Will there be a mechanism to copy changes from the active directory -> staging (to simplify versus a person going into the config directory for these components).
• Does the staging directory get emptied out after the changes are synced from staging -> active?
• If so, then is the strategy from the devops standpoint to reset that directory prior to a git pull?
• If not, then is it correct to assume that while staging->active sync occurs, there shouldn't be any affect on configuration that has not changed?

Anyways, please post followup questions there as we can bring it back into the fold here.

Updated issue summary.

If the staging directory is cleaned out on import, I'm looking at using a third "dev" directory, with a script to sync the current contents of the active directory to that (a folder action works nicely if you're on a mac). Put the dev config directory into version control, then there is no need to reset staging config prior to a git pull.

This issue was filed a while ago and is not getting much attention. I suggest we close it and here's a possible workflow now that Drupal 8.0.0 is out: https://docs.acquia.com/cloud/manage/code/config-d8