Practical staging of config

Question

I am successfully migrating at least the bulk of my config from dev thru stage to prod. But the process could obviously be more robust.

Current procedure:

• create central (bare) repository
• create dev
  • clone to dev machine
  • perform set-up (usually standard template) using separate sites/dev.mysite.com settings. No content. No real settings beyond the defaults imported from the template and the install.php process.
  • export config to from_dev config dir
  • push all to central repository.
• create stage
  • clone to stage
  • perform identical setup but using sites/stage.mysite.com instead.
  • import config from the from_dev config dir
    • use drush config-edit to change the freshly created UUID's for system.site and shortcut.set.default so they match the UUID's from the dev site.
    • use drush config-import to duplicate the config from dev.

Basically repeat this process for any other sites in the staging tree.

Problems:

• All the sites now have identical UUID.

  I'm not clear on the value/purpose of UUID but as long as they are all unique within a site; I'm not sure that's a problem?

• The import process does not have the ability to modify existing config objects when the change is limited to UUID. If the UUID's differ, the old object is deleted and the new (otherwise identical object) is created from scratch. This has the side effect of also deleting any content associated with the old object.

  In theory, this sort of delete/replace only happens during initial setup before the sites have any data; so there's no harm. However, great care is obviously required to guarantee that no "important" object will be deleted thru the entire life of the project.

Is this an intended D8 workflow?

Should the UUID (either in the live target stage site or in the configs from dev to be imported) be edited to match before the import?

Is there anyway to instantiate a D8 stage (prod) site that is genuinely "blank" (i.e.: an initial config import would require no editing of UUID and/or deletion/recreation of config objects)?

I've been using the standard template because it includes things like Configuration Manager which facilitate the config sharing process. Note that if stage is not built with the same template as dev than the import will fail with something like (paraphrase from memory): Unable to uninstall module 'minimal' because it does not exist; Unable to install module 'standard' because it does not exist. Is there a better template for this process?

Answer 1

I would approach it this way:

Have a branch master:

Create 2 separate branches fed from the master (master being prod): - stage - test

Create a new branch abcfeature based from master, after complete, merge to stage/test.

Use domain alias's to setup different URLS in your test environment.