Wouldn't you agree that managing configuration is vital in the life-cycle of a multi-person project? Well, its importance used to be, until recently, proportional to its main dreaded feature, that of being a major nuisance for web development teams: highly important configuration settings were missing, leading to major inconsistencies when it came to configuration handling, commits, made by the members of the team, resulting in conflicts etc.
Have no fear, Drupal 8 Configuration Management System Is Here!
That's right, Drupal's latest version comes to relieve your team of all the stress that parallel configuring actions might lead to. Upgraded with tempting configuration management tools, it allows developers to export/import all the configuration settings they will have performed to/from code.
Moreover (and this is the very best part of Drupal 8 configuration management system), Git allows the members of your team to put configuration under version control, thus keeping track of it (the ultimate goal of any configuration management endeavor, after all!).
What does this mean?
1. that you'll have a history of all configuration changes
2. that you can compare different configuration states
Do you already have a a development version Drupal 8 installed on your system? Is Drush available there, as well?
Well, before you go any further we have a "warning”/piece of advice for you:
Make sure not to put the files/folders that came with Drupal specific setup (e.g. sites/default/settings.php, sites/default/files/, sites/default/files/css/ etc.) into your repository! How to avoid that? Just make a clone of the "example.gitignore" file (that you get with Drupal) and place it in .gitignore, then adjust it to your website's specific needs, thus keeping the files directory and setting.php unexposed to the risk of getting versioned.
Initiate The New Repository
Once you've downloaded your Drupal 8 version, simply initialize and register a new repository along with it:
$ git init
$ git add .
$ git commit -m "Initial Commit: Drupal 8.x Code base"
Great! Now consider this: Drupal 8 configuration management system only works on distinct instances of the same website! So, what solution do you have? You simply clone it: import the database of the website to be cloned in the other environment!
Next, add your remote repository clone URL:
$ git remote add origin REMOTE_CLONE_URL
Push the commit up to GitHub:
$ git push -u origin master
... and voila: you have your new functional Drupal 8 website!
Now let's start “playing” with the Configuration Management System that Drupal 8's developers "spoil" us with, easing our work by giving us full control over all the changes we (along with out teammates) will apply to our site later on during its development process!
Go ahead and export your configuration
After you've set up the needed configuration, it's time to export it. How? Use the command line for exporting the site configuration to a new folder (config/site):
$ mkdir config
$ drush config-export --destination=config/site
Next, commit and push the configuration to the repository.
There, you've just created your own "safe", the one that stores priceless website information!
Practically, you now have a valuable screenshot of how your website looked like when you installed it. From now on, dare and perform any configuration you'd like, knowing that at any time you can just roll back your site to precisely this state: the one right after its installation!
Time To Import Your Configuration
For importing your configuration from the config/site, rely on this "powerful" command:
# Import the configuration from the repository
$ drush config-import --source=config/site
Why powerful? Because it instantly overwrites the current configuration!
It's after you've exported your configuration that you can merge it with those of other members of your web development team:
- add and commit the configuration to Git
- use Git pull, then focus on fixing any commits conflicts that might arise
At this point, we have another warning/helpful piece of advice for you: don't rely exclusively on Git for the configuration's merging part. Be sure to check whether the result of the merge is correct, whether it makes sense!
If everything will have gone smoothly with your configuration's importing process, you can go ahead and push it to the remote repository.
Valuable Pieces of Advice
1. Always export configuration first and pull the configuration changes run by your collaborators secondly! Why? Because Git doesn't recognize the changes will have have applied to your database until you actually export them!
2. Always import first, push secondly! This means that it's always safe to import the configuration and only then to push it to the remote repository, avoiding the risk of breaking the site (in case you're dealing with a broken configuration)
3. Accompany each import with a database dump, thus granting your team a backup in case anything goes wrong
4. Deal with this thought: you can't rely on Git for everything! Don't loosen your vigilance, especially when you're a member of a larger team working on the same project!