How do I deploy/manage similar sites from an unique profile, without dumps? 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
Features can help bypassing the UUID problem. It's still buggy, which prevents us from fully automating the process, but we can at least shift and maintain configuration manually.

Features still creates modules, it exports the configuration into the config/install directory of the given features module. This will be picked up when you install the feature, and you can continue to update your site config (similarly to what the old drush features-revert did) as your features export changes.

You can also import configuration directly via drush, make sure to use the --partial flag, to avoid overriding configuration not in the config folder. Using --source you can also define a custom configuration folder location, so you can do something like drush cim --partial --source=docroot/modules/features/myfeature/config/install.