0

I have the following scenario:

I will develop an application based on Drupal. Everything will be developed on a local instance. Composer files, configuration and so on will be kept in a git repository. The repository will be hosted on GitLab. I will use the CI/CD features over there. I will need one test instance.

The project starts with one production instance. In the future, there will be additional production instances. They all should have exactly the same configuration, but different content.

I already did something like this, where I copied the initial database from my local install to my test and production server. Afterwards, my CI/CD scripts could load the configuration from git to the different instances. But there, I only hat one production server.

If I remember correctly, configuration is bound to an ID of the initial database. So, I can't just set up a new instance and load the configuration from the old one.

Since they all will have exactly the same configuration, I would love to have a develop branch for delivering to the test server and a master branch to deliver to all production servers. If there are better solutions, I'm also open for them.

What would be the best workflow to add additional instances in the future that use the same config and can receive updates from the same CI/CD?

Would this workflow be completely incompatible in the case that, somewhere in the future, one instance would start getting additional configuration?

Improve this question
2
  • With the minimal profile you drush site:install --existing-config. Otherwise, like with the standard profile, you only have to ensure the new site has the same UUID (you can set with Drush as well) and then import the config from the other site. Or make your own profile.
    – leymannx
    Commented Nov 27, 2020 at 19:03
  • 1
    Ahhh, I didn't know that there was a way to set the UUID afterwards. That's great news for me. Actually, the --existing-config seems also to be interesting. Have to see, what matches best for my composer CI/CD workflow.
    – flauschi
    Commented Nov 30, 2020 at 14:33

1 Answer 1

Reset to default
0

Would this workflow be completely incompatible in the case that, somewhere in the future, one instance would start getting additional configuration?

If having one instance with divergent configuration is a concern, it is probably worth considering setting it all up as a distribution.

While rolling your own distribution may be overkill, this provides the most "future-proofing" long term because you will have a base configuration in the distribution that can be overridden on a per-site basis if it becomes necessary.

Rough documentation on configuration in distributions

With a distribution, in addition to default configuration, you can even include default content.

Improve this answer
3
  • Correct me, if I'm wrong, but to me this sounds like building the site ones, converting the configuration to an installation profile and starting all the pages with this profile. Now, I would be able to change configurations on the independent installs, but common changes for all of them would be difficult, wouldn't they?
    – flauschi
    Commented Nov 30, 2020 at 14:41
  • Currently, upstream updates are being handled in a variety of ways and this is not a standard approach. See drupal.org/project/drupal/issues/3004662. The approach in my answer adds a lot of complexity based on the idea that "one instance may need additional/separate configuration" at some point in the future. Whether this additional overhead is worth it or not really depends on how likely/the extent of that additional config.
    – Patrick Kenny
    Commented Dec 1, 2020 at 3:29
  • Wow, OK, looks really like there shouldn't be an option for diverging instances in this project. Thank you.
    – flauschi
    Commented Dec 1, 2020 at 15:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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