15

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
3
+50

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.

  • ok, if I understand it well, you use feature to synchronize websites configurations on soime keys features. Without allowing the full config-sync of cloned websites. – regilero Jan 29 '16 at 13:56
  • 2
    Exactly. For us the fundamental problem with full config synch is that its enough to have just one setting that the admins can change, and you can no longer sync, because that would revert their change. Breaking it up into feature areas allows us to a) maintain a configuration set (partially, because we understand what is it) and b) remain flexible on the rest of the features and how we manage their configuration. – Balazs Dianiska Feb 2 '16 at 19:44
  • Ok, this is maybe not the definitive answer but I'll give you the bounty. If someone wants to add an updated answer later (as things are moving) I'll maybe reopen another bounty for that. – regilero Feb 5 '16 at 12:48
1

Another option:

drush config-set system.site uuid 56974bf2-68c2-3453-a211-de8bc754cc23
0

Based on @Ivan Jaros hint, you can set certain configuration options upon installing a profile. Obviously, this only works on installation and not once a site is already installed.

In the .install file of your profile, you can add in default configuration settings in hook_install():

\Drupal::configFactory()
  ->getEditable('system.site')
  ->set('uuid', 'this is my new uuid')
  ->save(TRUE);

I have tried this locally and it does work. I was able to pull config from another site into a freshly installed local site using the code above (with the proper UUID set) without using drush cset to change the site UUID.

Presumably, you could set your UUID to be taken from a file on your environment somewhere, or an environment variable, or service, and thus they would all be the same on any site with that profile installed.

I hoped to do a similar thing from settings.php but the ConfigFactory class isn't available at that point and as you point out in your question setting it via $config in settings.php has no effect.

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.