This article was automatically recovered from archived versions of this site via the Wayback Machine. It is likely outdated or contains formatting errors, as it has not been reviewed.

Using Features to Streamline Deployment and Maintenance

November 20, 2012

drupalfeaturesmaintenance

I have to admit, I joined the party a little late. That’s mostly because I really didn’t have the need to go down the “feature-road” so far. There’s already tons of “features” floating around and most if not all Drupal distributions rely on this module for one or more .. snareroll .. features. :-)

My need to look into features arose because of a project I’m currently working on which heavily depends on automatic maintenance and deployment of features to multiple Drupal instances. Turns out that features is the perfect tool for that. In combination with drush, rules and a bit of glue-code, one ends up with a nice and stable way of haveing centralised management (something like Aegir in a way) of Drupal instances.

After my positive experience, I slowly started to create features for generic aspects of sites I manage. For example, the “Page” content types or generic “Blog” content types with an attached, blog-like view for display. It’s a little tricky to overwrite existing configurations with features, for example the mentioned “page” content types. But it’s doable.

It’s especially nice because I like to optimise the user experience of CRUD-forms over time. For example using field groups or adding features to file field sources upload widgets. Or removing them, if they prove to be counter productive. Now with features in place, I can update a content type structure of managed sites without the hassle of the “replication: click-by-click”-method. Another great addition to the drupadmin-toolkit is strongarm, which provides variables as exportable entities. A lot of contribs offer exportable profiles, like ckeditor, linkit, views, rules and more.

I am really surprised by the stability of features, the dependency checking, the notification on differences between a feature and the current settings of an instance, the problem-handling and the ease of use in general. The next thing I will implement is my custom staging solution to use recreateable features instead of manually messing around on the database level. Something nice would be exportable block configurations per theme. Let’s see.