Manage Drupal 7 Configurations using Features built with Features Builder

Most of us have been using the Features module for configuration management in Drupal 7 for years now.  This is not what the module was originally intended for, but it has allowed us to move variables and configurations that were kept in the database into code, so they can be transferred from development to staging and production sites.

Features is a module that creates other modules.  It was designed to bundle together functionality, say for a blog or a gallery, so you could deploy that functionality to multiple sites.  If you can think of grouping together a Content type with it's fields, dependencies, and views and you are thinking along the lines of the original design.

However, somewhere along the way, some smart people figured out that we could send a lot of configuration to code using Features.  Different ideas of what should be kept in each "feature" arose, and a pseudo-configuration system evolved in Drupal 7.  Features provides a User Interface in the Drupal admin where developers and administrators could click together variables that go into a feature, and click together we did.

I was taught how to use Features for configuration management by Will Long, the creator of the Features Builder module.  Will gave a great presentation at last week's Drupal Chicago meetup describing how Features, and Features Builder works:
http://presentations.kerasai.com/cadug-features-builder/

Here is a video of a similar presentation he gave at this past summer's Twin Cities Drupal Camp:

His blog post, Organizing Features for Configuration Management explains the methodology on how the Features Builder builders are put together.  Starting a project using this system was always well planned and organized.  However, as the project went on, as developers left and new ones joined the development of the site, the more we were unable to remain consistent in how we clicked together our features.

The Features Builder module takes the clicking out of the mix by pre-defining which variables get sent to which Features ahead of the build.  This takes the guess work of selecting which variables go in which features away from the individual developer, and provides consistency from project to project.  If you don't like the predefined builders, you can build your own according to your own methodology.

This module has really streamlined our professional workflow.  Instead of futzing with features at the end of every build we run a simple drush command, compare the changes, and commit and push.

Installing Features Builder

# Download Features and Features Builder
drush dl -y features
drush dl -y features_builder
# Enable Features, Features Builder, and Features Builder Default
drush en -y features features_builder features_builder_default

Features Builder Workflow

# Run Features Builder
drush fb -y
# git status to see what has been exported
git status
# Git Diff to see what has changed in each file.
git diff /sites/all/modules/features/filename.file
# If you approve, add and commit your changes
git add -A
git commit -m "Very descriptive message here"

After that, push and/or deploy your changes to your live server, and revert your features, from the database to code as you normally would.

Moving Forward

Configuration management in Drupal 8 has made this system not needed moving forward, but for our current and near future Drupal 7 sites, we can gain a lot of consistency and productivity by using Features Builder.

Features is going to continue to exist in Drupal 8, as it was built to be, a Feature manager.  The creator, mpotter introduced Assignment Plugins, in which plugins can automatically assign existing site configuration into packages, an idea that is similar to Features Builder.  For more on the future of Features, checkout this great blog post.