Drupal's Features module tends to use this pattern: The code defines the default configuration. If the user changes the config using the UI, the change gets w

Drupal's Features module tends to use this pattern: The code defines the default configuration. If the user changes the config using the UI, the change gets written to the database. At the same time, a little telltale light (or something) tends to appear in the UI display, to alert the admin that something's been changed on the site, but not in the code. Your developer can then come along and pull a report that lists any configuration that's been changed in the UI but not migrated to the code. Pressing a button spits out a code-based representation of that configuration. The developer finds the right file, pastes in the config change, checks into Git or SVN. Now the config is once again captured in code, and ready to be deployed in a consistent manner. I'm not sure if the Drupal 8 team is using this pattern or something different. Still trying to catch up with this stuff.