The following are notes from the developer's summit breakout meeting. This is in a wiki page so all attendees can update the notes with their own observations from the meeting.
Goals
- Reliable and fast deployment process
- Optimize version control
- Allow data considered "content" to also be deployable
Distinguish content from configuration
Although we, as developers, think this should be made more clear in Drupal, we may need to stop pretending that Drupal can do this. Clients want content deployment. Developers want to be able to bundle and redistribute content (e.g.: install profile). The new entity system will begin to severely blur or even eliminate the definition of content-only data.
UUID
- Has been stalled by token support in core. Many areas to investigate, such as avoiding UUIDs in URIs.
- Can start with:
- Role IDs
- Format IDs
- Vocabulary IDs
Exportables
Implementation in core is relatively easy. Its low hanging fruit. We can get it in, and start solving problems now. However, there are issues with how exportables are implemented now that will need to be fixed long term. The ability to hook_form_alter any form and add your own data is very prevalant in typical Drupal development practices.
Data that is both related and integrated. For example, the location module both attaches location data to a node, while also maintaining a seperate location database. This is implemented through a hook_form_alter. What is data? What is configuration? Is the location database considered data or configuration? Is the location considered a relationship to the node, or data that is integral to the node itself?
An ability to hook into the export process could help this. Location could alter both the form and the export to ensure its data travels with the appopriate export.
A New API for Drupal 8
It was proposed that this API could/should:
- Provide a central and generic way to store all settings including those that are larger (e.g. views settings) and don't need to be loaded on every page (as the variables are now)
- Save metadata related to settings so that they can be related to modules, themes, and one another allowing for easier loading/saving and exporting
- Make all of these settings exportable by default
- Allow these settings to be specified in at various levels, each overriding those before
- In modules/themes
- In the database
- In settings.php
- Allow settings to be altered
- Allow the storage of these settings to be swappable allowing for static file or a separate sqlite backend (mostly to get settings into version control)
- Allow modules to register be notified of settings changes (for modules like Fields API (CCK) that need to make db changes when configuration is modified)
- Detect and notify modules when changes are made, even in code
- Allow settings to depend on modules (and more importantly: specific versions of modules)
- (potentially?) Log settings for undo, rollback, replay, replication
tizzo has started working on a proof of concept system settings API on github. It's very rough, incomplete and probably broken right now. Patches welcome!
Issues with this approach
- May be unnecessarily complicated
- UUID + export.inc + alter = 95% of what we need
- May be unnecessarily reinventing version control
- This approach may solve the deployment problem for configuration but does not touch on content, it was suggested that perhaps we need to accept that content and configuration are the same thing in Drupal
What do we really need from Drupal core at minimum?
- Unique Identifiers
- export.inc
- Alter support in export.inc
Articles/Modules Mentioned in the Session
Articles related to deployment:
- Drupal release management and Deployment BoF - Colingo Labs - Slides from the session
- Dev -> Staging -> Release Config Management
- The Case for a System Settings API
Modules that attendees have found useful in baking their own deployment solutions: