What is the suggested workflow for migrating (CMI) configuration from dev -> stage -> production? We had a drupalcamp a few months back and someone asked about managing deployments with the new config (CMI) system. One possible ideal workflow would involve keeping the config in version control and still being able to migrate configuration between team members.

The best that we in the room were able to figure out (partially based on the presentation at DrupalCon Portland) was:


Tell version control to ignore active config directory.
Copy all Configuration over to staging directory and commit to version control.


And use settings.php to reverse active/staging directory between the 2 environments. However, 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) - A possible issue would be every team member would be sharing the same or similar environment so how do changes on one teammate's machine come over?
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).