Configuration management is an increasingly important foundation in the technology world that is supposed to solve all the woes faced by modern Content Management Systems (CMS). Be it Drupal or any other CMS, configuration management has made things easier than ever before and has positively impacted business and its related activities. There is no denying the fact that configuration management is important for any business as the term configuration is what makes your system work. 

With the increase in the number of Drupal 9 installations, there is a simultaneous increase in the number of burning questions on Drupal 9 that have sprung up. One of the key questions is around Drupal 9 configuration management strategies. However, configuration management in Drupal 9 is not as easy as upgrading to Drupal 9.

Therefore, if you are here to know what it takes to implement Drupal 9 configuration management strategies, then you are in luck! In this blog, we will be giving a detailed insight into Drupal 9 management strategies, followed by the factors to drive the same. But before we start, let’s take a step back and understand what configuration management actually is all about in Drupal. 

Configuration Management: An overview

To begin with, configuration management is a form of IT service management that is held responsible to establish and maintain the consistency of a product's performance, functional, and physical attributes with regards to the requirements, design, and operational information throughout its lifecycle. The prime objective of configuration management is to make sure that you can review, test, and predictably deploy all configuration changes to production environments.  

The configuration is the collection of admin settings that determine how the site functions, as opposed to the content of the site which is typically captured and deployed through YAML files. In Drupal, site configuration data is stored in a consistent manner which typically includes everything, right from the list of enabled modules to content types, taxonomy vocabularies, fields, and views. Configuration management has come a long way in the Drupal world. In other words,  the former has undergone necessary changes and has transformed a lot from what it was in Drupal 7 and Drupal 8. 

In Drupal 7, both configuration and content were kept safe in the database. As a result, contributed modules like Features were assigned the task of moving configuration to other environments. Drupal 7 configuration was going well, however, the configuration wasn’t effortless as it could be which eventually led to the change in configuration management in the later version i.e. Drupal 8.

Drupal 8 being the latest configuration improvement after Drupal 7, was able to deliver better and faster configuration management. In Drupal 8 Core, configuration for most site settings as well as for the definition of structural pieces can be exported easily with one click of a button or a single drush command. Further, you were allowed to commit and merge configuration changes in source code control, deploy the configuration, and then import it into the destination environment. Having a configuration management roadmap also helped with improvements made in Drupal 8 releases. For instance, the support for creating new sites from existing configuration was included in Drupal 8.6.

Configuration management strategies in Drupal 9

Drupal 9 configuration management is a bit rough process that comes along with some problems to wrestle with. In other words, there are some significant challenges in the pathway of Drupal 9 configuration management that do require some additional strategy or planning to better understand how you will utilize the configuration management system. Some common configuration strategies include the following-

1.  Apply Complete Config Sync:

Overview:

• all configuration is transferred into a configuration sync directory 
• config split and config ignore enhances the core config system
• drush manages config imports/exports
• ideal automated config imports during deployments
• config imports should occur following database updates

Appropriate for both site and profile config splits, this strategy can work wonders when you have a common set of configurations (90% or greater) that is shared across all splits and further deploys the split and/or config ignore to handle specific cases wherever necessary. Not to mention, this strategy can go wrong if you have a large platform and each profile/site has a large quantity of unique/bespoke configuration. 

2.  Apply Partial Config Sync:

Overview:

• config is kept in module/profile/theme config directories and installed only when the respective parent container is installed
• database updates and drush make the necessary updates to config 
• contributed modules such as config split/config ignore are generally not required 

Regardless of being flexible in nature, this strategy often ends up with multisite platforms which are almost impossible to update owing to the unintended consequences of changes and development. Moreover, unlike the monolithic approach, the partial approach does not have paradigms that can help you keep troubles at bay. As a result, this strategy puts you in a predicament which is certainly difficult to get rid of. 

Factors to consider while formulating a strategy

One of the biggest mistakes that any developer can make is to start planning without considering the best factors. Sounds bizarre? Well, this happens for real. It has been observed that most of the Drupal-based sites value the end-product more than what they have on their plate because of which the development team leads to failure. 
 
As a matter of fact, creating the product breakdown structure i.e. pre-considering the necessary factors can help you deliver the end product in the most efficient manner. There are three key factors that are of supreme importance and required to be considered.

Differentiate between a single site, multisite and many sites

Configuration management strategies in Drupal 9 are highly driven by the architectural considerations and decisions that cannot be overlooked.   

• Single Sites: It includes one single site running a single codebase, database, and file system.
• Multisites: It includes sites with a single codebase but separate databases and file systems.
• Many Sites: It includes sites with separate codebases, databases, and file systems that still somehow derive from a templated/distributed codebase.

Note: While a single site may consume the configuration stored in their codebases entirely, multisites and many sites are much less straightforward and have at least some varied config.

Find variation in features

Next in the row is feature variation which focuses on the commonality of features that you provide on your platform. 

For example- you are building a multisite codebase where your customers want to have a hero carousel but have clashes relating to the hero banner. One of the customers demands a horizontally scrolling carousel with a background image and call to action. On the contrary, another customer demands a vertically scrolling carousel with a background video. In such a scenario, a common feature is a carousel that needs to be taken into consideration while creating a configuration management strategy. There are two ways to perform this- 

• Build two hero carousels that offer the same things with little or variation.
• Build one hero carousel that offers a few extra fields to allow changing the scroll direction, background type, etc.

Group the identified features 

Once you have successfully identified the features, it’s time for you to invest some time in grouping these features. Generally feature grouping falls under four major categories.  

• All Drupal sites share the same config 
• Sites are categorized into profiles/distributions. Further sites within these groups share the same config 
• Regardless of the fact that each site requires individual configuration, they still share the majority of their config 
• Each site possesses bespoke configuration and is entirely unique in nature.

Tools of the trade

When it comes to Drupal 9, formulating a configuration management strategy won’t suffice. That is to say, you might need to arm yourself with some key modules/approaches that can help you sail through the complex Drupal process. In a separate blog, we listed down the must-have modules to start your Drupal 9 project. Here, we will throw light on some Drupal 9 modules that will help strengthen your configuration management strategies. Let’s have a look at them. 

Configuration Split Module

The config split module enables you to define sets of configurations that are required to be exported to separate directories when exporting and get merged together when importing. Further, you can also define in settings.php which of these aforesaid sets should remain active and further consider for the export and import.

Configuration Ignore Module

The config ignore module is basically a tool that helps you keep the configuration you want, in place. If you would like the system.site configuration (including the site name, slogan, email, etc.) to remain untouched, on your live site, no matter what the configuration in the config folder is, then this module is what you are looking for. Also, this module is the best way to save yourself from the grueling devel settings that change every time you import configuration.

“Installed” Configuration 

Tied up with a module/theme/profile, this config is installed when that thing is installed. Not to mention, the feature module uses the same approach that the installed config uses. 

Conclusion

To conclude, we hope this article has summed up everything that you have been looking for. While Drupal 9 configuration management is still a complex process, it is indeed a great step forward in a world that constantly undergoes technological shifts. Further, configuration management in Drupal 9 requires a team of professionals that are proficient enough to understand how configuration management works, what is it capable of, where its shortcomings are, and how to merge and resolve conflict. 

Want to learn more about Drupal 9 configuration management? Contact us at hello@opensenselabs.com and our industry experts will help you spot and resolve the issues encountered at the strategy stage.