How we are improving Drupal's configuration management system

Tue, 30 Oct 2018 13:39:19 -0400

Configuration management is an important feature of any modern content management system. Those following modern development best-practices use a development workflow that involves some sort of development and staging environment that is separate from the production environment.

Given such a development workflow, you need to push configuration changes from development to production (similar to how you need to push code or content between environments). Drupal's configuration management system helps you do that in a powerful yet elegant way.

Since I announced the original Configuration Management Initiative over seven years ago, we've developed and shipped a strong configuration management API in Drupal 8. Drupal 8's configuration management system is a huge step forward from where we were in Drupal 7, and a much more robust solution than what is offered by many of our competitors.

All configuration in a Drupal 8 site – from one-off settings such as site name to content types and field definitions – can be seamlessly moved between environments, allowing for quick and easy deployment between development, staging and production environments.

However, now that we have a couple of years of building Drupal 8 sites behind us, various limitations have surfaced. While these limitations usually have solutions via contributed modules, it has become clear that we would benefit from extending Drupal core's built-in configuration management APIs. This way, we can establish best practices and standard approaches that work for all.

The four different focus areas for Drupal 8. The configuration management initiative is part of the 'Improve Drupal for developers' track.

I first talked about this need in my DrupalCon Nashville keynote, where I announced the Configuration Management 2.0 initiative. The goal of this initiative is to extend Drupal's built-in configuration management so we can support more common workflows out-of-the-box without the need of contributed modules.

What is an example workflow that is not currently supported out-of-the-box? Support for different configurations by environment. This is a valuable use case because some settings are undesirable to have enabled in all environments. For example, you most likely don't want to enable debugging tools in production.

The contributed module Config Filter extends Drupal core's built-in configuration management capabilities by providing an API to support different workflows which filter out or transform certain configuration changes as they are being pushed to production. Config Split, another contributed module, builds on top of Config Filter to allow for differences in configuration between various environments.

The Config Split module's use case is just one example of how we can improve Drupal's out-of-the-box configuration management capabilities. The community created a longer list of pain points and advanced use cases for the configuration management system.

While the initiative team is working on executing on these long-term improvements, they are also focused on delivering incremental improvements with each new version of Drupal 8, and have distilled the most high-priority items into a configuration management roadmap.

In Drupal 8.6, we added support for creating new sites from existing configuration. This enables developers to launch a development site that matches a production site's configuration with just a few clicks.
For Drupal 8.7, we're planning on shipping an experimental module for dealing with environment specific configuration, moving the capabilities of Config Filter and the basic capabilities of Config Split to Drupal core through the addition of a Configuration Transformer API.
For Drupal 8.8, the focus is on supporting configuration updates across different sites. We want to allow both sites and distributions to package configuration (similar to the well-known Features module) so they can easily be deployed across other sites.

How to get involved

There are many opportunities to contribute to this initiative and we'd love your help.

If you would like to get involved, check out the Configuration Management 2.0 project and various Drupal core issues tagged as "CMI 2.0 candidate".

Special thanks to Fabian Bircher (Nuvole), Jeff Beeman (Acquia), Angela Byron (Acquia), ASH (Acquia), and Alex Pott (Thunder) for contributions to this blog post.

Configuration management in Drupal 8

Mon, 28 Mar 2011 08:18:25 -0400

In my DrupalCon keynote in Chicago, I talked about the key initiatives that I believe we should focus on for Drupal 8 core. One of those key initiatives that I talked about was configuration management.

For some, configuration management is a bit of an abstract term. In short, it refers to a mechanism for handling configuration changes. Site owners often want to have fine-grained visibility and control over configuration changes with the purpose of maintaining integrity and traceability throughout the life-cycle of the website. For example, they might want to lock down a site's configuration so site builders can't make changes in a production environment, they might want tools to automatically apply a set of configuration changes made to site A to site B, they might want to rollback changes, or go back in time to see who made what configuration change when. It will also paves the path for better staging; some site owners want to be able to merge user generated content into their development environment, and new content back to the production.

To enable all of the above in a modern and elegant way, we need to make a number of changes to Drupal. These changes will be worked on as part of the Configuration Management Initiative for Drupal 8 core.

Greg Dunlap (and David Strauss)

Also in my DrupalCon keynote in Chicago, I outlined changes to the Drupal development process. Each of the Drupal 8 initiatives will have an Initiative Owner that reports to me, and that acts as a project manager and/or technical lead.

I'm excited to announce Drupal 8's first initiative owner today. After some back and forth with various people and in-person meetings, I've decided that Greg Dunlap (aka heyrocker on drupal.org) will be responsible for leading Drupal 8's Configuration Management initiative. Not only is Greg both passionate and knowledgeable about the about the topic of configuration management, his employer NodeOne has generously offered that Greg can work on it half of his time.

I've also asked David Strauss to be an 'architecture gatekeeper' for the Configuration Management Initiative. He needs to sign off on the architectural choices and the API design. Like Greg, David has been an evangelist for better configuration management in core. When both Greg and David are happy with the implementation, I'll consider including it in Drupal 8 core.

For more details, read Greg's announcement blog post, or better yet, participate in the design discussions.