Deployment & Build Systems & Change Management

This week at DrupalCon London, all the initiative owners gave status updates on the progress they are making and where they currently stand. Unfortunately not all of them were recorded properly, but mine was so anyone who is interested can watch the video here

http://blip.tv/drupalcon/drupal8_full-5494012

The slides are also available here

http://www.slideshare.net/heyrocker/drupl-8-configuration-management-ini...

Welcome to another discussion from the configuration management initiative! So I believe that in the last thread we pretty much got everybody on board with the idea of 'We can use pure JSON as our file format if we use a hashed directory name and don't write the files by default.' This is great, however it then led to more discussion of 'Why are we using JSON anyways? Why aren't we using PHP/YAML/INI/LOLCODE etc.' Some good points were brought up in this discussion and I think it is worth hashing this out now.

Last week, before DrupalCamp Colorado, Greg "heyrocker" Dunlap, David Strauss, Larry "Crell" Garfield, and Karoly "chx" Negyesi met to hash out architectural details and whip up some prototype code for the Drupal 8 Configuration Management initiative.

What problems are we trying to solve?

• Currently there is no good way to move Drupal configuration information between environments because this data is scattered throughout the database in a variety of formats, oftentimes intermingled with content.
• This also makes it impossible to version control this information, to store history, and to be able to rollback changes.
• Every module stores their configuration data in a different format, there is no standardization at all, even within core.
• There is also no standard API for saving this information (aside from the simple case of the variables table) so developer often roll their own solutions.
• The entire contents of the variables table is loaded on each page request, even for rarely-accessed data, leading to memory bloat.
• It is cumbersome to manage information that is different between server environments for the same project (database information, api keys, etc.)

We specifically are NOT (yet) trying to solve the problem of contextual configuration; only the underlying API that handles getting/setting this configuration data and shuffling it around to different sites.

The code that was developed at the sprint as a prototype is available at http://drupal.org/sandbox/heyrocker/1145636 for your reviewing pleasure. The main things to look at are the includes/config.inc and modules/config/config.test files.

What follows is a summary of the results. Your feedback is welcomed!

The twin deep-engineering Core Initiatives of Configuration and Web Services have been taking a long hard look at Drupal's basic, underlying architecture of late. We're swirling around three fundamental pieces that should, we believe, revolutionize Drupal core and Drupal development, allowing for a quantum leap in Drupal's capabilities. (Excited yet?) The catch is, we have to get these right. More than that, we need to nail these. For that reason, we're trying to solicit wider feedback on a few key architectural questions. I have tried to summarize the situation and the challenges below, and invite informed, insightful feedback from the community.

The three cornerstones of this new approach are Configuration, Context, and Plugins. All three are things that Drupal core does not, in fact, provide in anything resembling a useful way. We need to get all three of them into core, however, and they need to work together well. The problem is that there are very good reasons for all of them to require one of the others first, which creates a circular dependency. We need to sort out that problem before we can get building.

This is a proposed game plan for managing configuration information in Drupal 8. This is focused on config data - the kind of thing that is currently being managed by the variables system as well as more complicated items like Blocks or Views.