Configuration management is a tricky situation with Drupal, but to run a sustainable project we have to have reliable, repeatable, and testable deployments. Drupal 8 is on the horizon with CMI, a standardized system for a Drupal site's project to save their configuration. Many developers rejoiced when this was announced back at the beginning of the development cycle, but we're still a ways away from that becoming the reality and we've got D6 and D7 sites to build and maintain in the meantime.
The accepted solution is to use Features to manage a site's configuration. Features was originally intended to provide a mechanism for units of functionality to be developed/configured then shared among multiple projects. It's not the exact right tool for the job of managing a site's configuration, but if you have a good understanding of what Features is and does and what the various pieces of configuration are then Features can be effectively utilized to manage configuration and deploy changes.
The goals of Featurization for configuration management are a bit different than Features that may be shared among multiple sites or by a distribution. The key concepts of making a Features sane and sustainable for the life of a project.
- Keep the organization simple, intuitive, and maintainable.
- Avoid merge conflicts with the VCS.
- Provide full coverage of a site's configuration, ideally.
- Build natural dependencies, prevent arbitrary dependencies.
- Allow changes to be reliably deployed.
I've been using Features for configuration management for several years now, and I've seen a lot of strategies that work well and a few that make me want to cry. There's not necessarily a right way to do it, but here's a look at the organization that I've settled on to make using Features for configuration management as pleasant and effective as possible. I encourage you to try it for yourself.
- Content Types
- Each node type used on the site gets its own Feature. This defines the actual node type as well as the field instances on the type and Strongarm variables that contain configuration for the type.
- Context
- All contexts built on the site go in here, along with dependencies to any module that provides a condition or reaction used by the contexts.
- Field Base
- Definitions for all fields on the site. All of them.
- Media Config
- All input formats and image styles, along with a few Strongarm variables used for image handling go in here. If running the Media module configuration for that and field instances on the file entities would be included as well.
- Pathauto Config
- Pathauto contains many Strongarm variables which are used to configure patterns and various behavior when generating aliases. I put all of those along with a dependency in its own Feature.
- Rules
- All rules I create go into one Feature, along with dependencies for Rules and any module that provides a trigger, condition, or reaction utilized in my rules.
- Site Config
- This is mostly Strongarm variables provided by various core and contrib modules. If a module defines it's own "component" to Features or has a tremendous amount of Strongarm variables I will usually put it in a separate Feature.
- Taxonomy
- If I'm utlizing the Taxonomy module, I'll create a Feature that contains all of the vocabularies as well as field instances on the term entities. Also any module that provides taxonomy-related functionality should have its configuration here, as well as dependencies to said modules.
- User Config
- Field instances on the user entity, roles, role/permission assignments, along with Strongarm variables used by the user module. If there are other modules that tie in with some function of the user I may add it as a dependency and add its configuration as well.
- Views
- All views used on the site go in here, along with dependencies to modules that provide plugins, field types, formatters, etc used by the view. Any module that provides data which is being queried by the views should have a dependency as well.
- XML Sitemap
- Strongarm variables for XML sitemap along with dependencies to it and any of its sub-modules are included.
This organization is only a road map and from time to time I make minor adjustments/improvements as well as special considerations on a case-by-case basis. Hopefully this gives you a good starting point for using Features for configuration management and please do contact me or leave comments with questions or recommendations.
Happy Feature-izing!