D8 Configuration workflow Notes

  1. D8 configuration is different, in that it is meant to capture the whole site from local>dev>stage>prod, instead of configuration changes captured in Features and encapsulated in individually importable modules, as in D7.
  2. That said, Features would still be employed for exporting a chunk o code / config for use in ANOTHER site, but once  the feature is imported, it all is a part of the site and managed though the core config management
  3. Configuration may be overridden on a particular environment through the $config array in a *.settings.php
  4. All feature/module default configurations are stored in YAML files that are dragged around as part of the config deployment.
  5. Config syncing (ie Stage>Prod) scenarios and solutions:
    1. Scenario 1: Configuration not managed at all.
    2. Scenario 2: Configuration sync directory in use, but sometimes configuration on the live site is edited: set up a local development instance, make and test your configuration changes there, export your configuration to files in your config sync directory, and finally use command-line tools like Git and Drush to deploy and import changes to the live site
    3. Scenario 3: Configuration changes are always made and tested on non-production instance(s) and then deployed to live: set up a strict workflow policy
    4. If you’re the one and only site admin and developer… learn how to use both GUI and command-line tools to manage and move your site’s configuration between instances.
    5. If you’re working on a team…