Ah, Drupal 8. It was the best of times, it was the blurst of times.
So if you've taken the dive into Drupal 8 and you aren't a person who helped build it, a person who helped test it, or the guy who invented it, then you know that it's a pretty considerable change from Drupal 7 and how to do things isn't immediately clear. Just try Googling for some kind of Drupal 8 tutorial and you'll find 5 outdated or flat wrong ways to do something for every one way that's right (for now). One of the areas we at Ashday were excited to jump into was Drupal 8's new configuration management system. As you probably know, managing database configuration changes and deployments in Drupal up to this point has been extraordinarily difficult. Well, with Drupal 8 things are much better! You see, it's now possible to export configuration from Drupal and it's not too hard to do so. Your content types, field settings, block placements, views, etc are all in there! The trick is how to use the tools properly, however, especially on a team. I'll outline what we first tried - which seemed so smart - and then where we ended up, which actually worked (again, for now). Like many things, the solution is simple - but often tricky to come to.
OPTION 1: Config management contrib modules
(NOPE! - not yet anyways)
Our first attempt at configuration management was to use the Configuration Synchronizer and Configuration Update Manager tools. These admittedly do look like the most promising direction for this, but they proved to be too unreliable just yet for where we were at. That was a month ago now so maybe some of the kinks have been worked out. In a nutshell, you can see what config is different from your stored yml files and then individually update or revert each item. This is great because in the dev cycle you undoubtedly find yourself wanting to pull some things in but not revert everything because you're working on something. We found though that in a number of cases the tool would show something as different, but then a reversion wouldn't cover every little setting in the yml file so somethings just stuck around as permanently changed. That list would grow and it just became untenable to use because you'd have to analyze each change every time.
Still though, if this stabilizes (assuming it hasn't already), then this is probably still a great solution.
OPTION 2: Hand-picked config files placed in custom module
(MAYBE? - not the way we were doing it)
Our next step was to take config that we cared about sync'ing and put it in our custom module. Make a db change you care about? Put it in the custom modules "optional" folder so you can sync it in. Well, we quickly realized we were doing that wrong. There are an awful lot of configuration elements affected by certain activities (try rearranging block order or tinkering with form display settings) that made it unmanageable to do that. Further, config in a module is not intended to be used the way we were using it. If it's a new install, it goes in "config/install" and runs when you flip the module on, as you would expect. If it's in "optional", it will install ONLY IF that config isn't present yet. Neither are the proper solution for regular changes to config.
OPTION 3: Complete dump and replace of entire configuration on every code pull or push
(DING DING DING!)
What we're doing now - which not suprisingly is more rooted in how Drupal 8 seems to want to do things - is dumping the entire site config (using Configuration -> Development -> Configuration Synchronization -> Export) into sites/default/config and then committing that to code. Then when a developer is working in a team, before he pulls he dumps his entire config into that folder and commits it and then a pull will reveal any changes. We rarely hit merge conflicts, but even if we do it's not too hard to sort out. Once that pull happens, the developer then imports EVERYTHING after the merge and bingo, his database is updated with all relevant config. In the end, it just turned out that there was literally no config that we didn't want to sync and way too much to understand to micromanage it the way we were. Further, we see only a very rare bug with the core Synchronize page continuing to show changes after an import, as we were with OPTION 1, and developers aren't too worried about understanding the nature of all of those changes either, as was the case in OPTION 1 or 2.
In summary, we're still figuring this out and there are a lot of growing pains both internally and in the Drupal 8 world in general so all of this is subject to change. ;) All we know is we've been using this strategy for weeks now and are finding it quite smooth and are no longer pulling shared remote databases on such a frequent basis to make sure other developer's changes work on our local environments. We're also much more familiar with how Drupal's admin UI translates to settings and aren't having to worry too much about it as long as we follow our procedures.
This holiday season we are grateful to Drupal 8's new amazing configuration system and also to the blood, sweat and tears it took to figure out how to use it.