I do not like the "cloning website" solutions which implies dumping a database and importing this dump in another environment. This does not look like a real world way of deploying several instances of the same website (staging/prod/dev/etc).
With D7 we usually used custom profiles and used drush to install websites from these profiles (and maybe using features for later site synchronisations). This provided us with fresh installations, no test content, but sharing important settings. Common content synchronisation would be done with migrate, for example.
I tried to manage several D8 instances sharing the same install profiles. Where the final goal would be to share and sync site configurations. And every installation has a different site UUID.
I have no success in enforcing the
system.site uuid config variable at install time (of course I can alter the value later, but it seems to me that this is too late, and all objects are already created with different UUIDs, which makes the first synchronisation a nightmare, where some default contents must be deleted, or default language crashing the sync because it cannot be removed, etc.).
To enforce this UUID I tried using a generated settings.php file with a
$config['system.site']['uuid'] value inside, big fail (the setting was completely ignored, even after site installation).
I've also looked at configuration installer profile, which I do not completely understand, especially the way to mix this solution with another install profile.
So the question is, what is the best way of deploying fresh sites from an install profile:
- without "cloning websites" and manipulating SQL dumps at site creation (like in what are cloned sites question ).
- with a fresh clean install (without developers content garbage), using the exported configuration and code only
- which can manage both install configuration defaults and later synchronisations