New Workflow Enhancement
The issue I was having was when exporting configuration and deploying via GIT to production. The performance settings were being exported as well, and thus, when importing to production, I was getting my development settings on production. This was not such a hassle, but it did mean I needed to re-enable cache and aggregation each time on production.
As such, configuration synchronization in Drupal is an awesome tool, and the idea that the complete configuration set is kept together makes sense. However, I knew there must be a better way for things like performance. (Side note: development settings are not part of the main configuration set, which is great.)
So, with a little research, I came across Configuration Split.
The idea behind configuration splits is that it splits your configuration into different directories. To be truthful, I have only scratched the surface with the possibilities, but for what I need, what I write here works; the system performance settings are not overridden on each deployment.
Setting Up Configuration Split
Install Configuration Split like any other contributed module. If you are unsure how to do that, check out How to install a Drupal module.
After you have it installed, you visit the Configuration Split settings page.
Manage > Configuration > Development > Synchronize
/admin/config/development/configuration/config-split
You can set up a Configuration Split setting on this page by clicking the Add Configuration Split setting button<.I am going to set up two types of configuration splits; the first one will be a complete split and the second one will be a partial split.
Setting Up a Complete Split
After clicking the Add Configuration Split setting button, you will be forwarded to a settings page. The page has a lot going on, but for a simple one-configuration item, it is pretty easy to navigate and understand.
First, you'll want to name your Split; I named mine Performance.
Next, we add the static settings.
Storage
Since I want to remove the configuration YAML file from the GIT repo, I am using a folder for storage.
Folder
Next is setting up the location of the folder.
It suggests using a sibling location of your config/sync directory. My config/sync is already at the recommended local of ../config/sync. So, as suggested, I added a /config/splits directory and a subdirectory performance like so ../config/splits/performance
Other Static Settings
- Weight: I left as 0
- Status: Leave Active.
Now, we can set up what we want to split. First up, I will do a Complete split.
Complete Split Configuration items
- In the Complete Split section, choose one item. In this example, I am selecting system.performance.
-
Once the item(s) is chosen, Click Save.
Note: It seems it is possible to choose multiple settings here. I think setting up individual configuration splits might be the best way. However, with more experience, you may find combining them will make no difference. I would err on the side of precaution starting.
Now, we need to set up the server and repository correctly to use the configuration split.
Setting up the directory and adding it to your .gitignore
The next thing you need to do is create the directory on each environment. (I did this on the desktop, laptop, development server and production server)
You can use the command line make directory command from in the root directory of your composer-installed site like so.
mkdir -p config/splits/performanceThen, add the directory to your .gitignore. I read this small hint on Stack Overflow, and this was a gem. If I didn't stumble across this, I may have gone down the rabbit hole.
Anyhow, make sure you add it to .gitignore right now, or you will later have to remove the file(s) from Git tracking. Here is the rule:
#config split to ignore
config/splitsConfiguration Export
Next, when you do drush cex (config export), all the configurations will export to the normal config sync directory except the performance configuration, which will go to your new untracked ignored directory. In the example below, you can see the system.performance YAML is deleted and a new config_split.config_split.performance YAML is created.
Perfect, now it's time to deploy to your other environments.
Deploy to Production or Staging
- Commit to Git
- Push everything to a Git remote repo, make a pull request, and merge into your main.
- Pull down main to production (or staging)
- Import using
drush cim(config import).
Boom! Performance settings are no longer overridden.
You may need to go to the configuration page for the settings you imported the new configuration to and set it for the environment. In this case, visit the performance settings page (admin/config/development/performance) to set it correctly.
Next, create the directory on the server. In this case, create the same performance directory.
mkdir -p config/splits/performanceAfter you have done that, run drush cex to save the instance settings to the config/splits/ directory.
Setting up a Partial Split
The partial split I set up is for the Backup and Migrate Schedule settings. I only need to back up the production website database daily.
Backup and Migrate makes it easy to disable the schedule in the UI, however, as with the Performance settings any changes made will be shared across all environment. A way around this is to use a configuration split.
A partial split is set up in the same way as the complete split we looked at in the previous step.
The first difference is the folder setting value. In the input, add a new folder.
The next difference comes when choosing the configuration items. Instead of using the Complete split section, we use the partial split section.
Since I only want to disable the daily schedule, I choose the backup_migrate.backup_migrate_schedule.daily_schedule item and then click save.
Next, create the directory that you added in the folder input.
mkdir -p config/splits/backup-migrateNext, make the change to the Backup and Migrate schedule setting and click Save.
Finally, you will want to run drush cex (config export)
That's it for this environment. If you check the config/splits/backup-migrate directory you will see it have created a patch file.
The patch file lists the differences to the default settings as shown following.
For this reason, on the production site, you will not get a patch file, as the scheduled backup and migrate settings will remain enabled, thus not needing a patch file.
Summary
In this article, we have looked at the Configuration Split module and how to set it up and use it with Git and, in particular using gitignore to stop the environment setting being included in commits.
We then looked at how to set up a complete split and then a partial split and how they are different under the hood. Even though the way the Configuration Split module manages the splits is different, the result is the same; you can have different settings on local development, staging sites, and production sites.
What I have covered here is great for a one-off configuration, and as I say, it only touches the surface of Configuration Split's capabilities. Enjoy!
I hope you enjoyed this article. By signing up for my newsletter, you can explore more interesting content on creating remarkable user experiences with Drupal and other technologies. The newsletter is on the intersection of design and front-end development. Sign up below.
Until next time, seize the day!