Raw Notes: Managing and deploying configuration with exportables and the Features module

Presented by Jeff Miccolis of Development Seed

(missed most of the beginning, talking about features and exportables)

• Ctools is special
• Strongarm gives you access to the variables table -- start to capture values from variables table
• these components are the configuration that descirbes how your site behaves - Strongarm lets you bring out and safeguard those important decisions
• Features should be used throughout the development process - not intended to come up later, meant to be there the entire time.

Creating a Feature

• Create a feature through the Features UI - add in various components
• Once you've built the feature, Features module gives you a way to see the status of the feature; lets you track whether any elements have been changed or overridden from what you set in your feature. Click Overriden, gives you a diff
• Using the Features web UI you can create a new feature, make updates to existing features, or revert the changes made from the prior iteration of the feature
• Drush has many Features commands - features (list all available features), features-export (export a feature from your site into a module), features-update (update a feature module on your site), features-revert (revert a feature module on your site)

Example of Features in development:

• Alex makes a feature
• Jeff pulls it down from version control, adds a couple of views to the features, updates the feature and commits in version control
• Young adds theme overrides
• Alex fixes Jeff's and Young's bugs
• Alex rolls the feature out
• Jeff makes views adjustments - when he clears his cache all of everyone else's changes to the feature reappear on his site
• Rolled out.
• Alex makes views adjustments to fix Jeff's...
• Young makes adjustments
• Roll out again
• Views changes are only made once. No need to manually copy stuff down, make changes on production AND staging, etc. Each change has a commit log within version control because everything is done in code.
• Process helps you avoid dumb errors; provides more accountability (making sure what you do is properly there; less likely for someone else to screw it up later; easy to enforce what's been done and figure out who did it.
• Overhead of staging goes away; go straight from dev to production.
• Not having a distinction between configuration and code is bigger than just this: you're able to maintain something like Open Atrium

Features for exporting Features as modules

• First: sequential IDs on configuration is the enemy. Use a machine name as the primary idea
• Second: when in doubt, use Ctools (http://civicactions.com/blog/2009/jul/24/using_chaos_tools_module_create...)
• Your job: database schema, UI
• Ctools' job: loading and exporting your configuration
• What's left: dependency detection, which is optional but useful
• hook_features_export() - lets you add modules, add components, allows for delegation

Best Practices around building Feature modules

• Kit - the goal is to offer a straightforward base package for building state-of-the-art Drupal sites while specifying how Features built on top of Kit can be compatible
• Kit includes Feature and Theme specifications
• kitf (feature specs): unique namespaces, user roles & permissions, variables, paths & menu items, block visibility & theme regions, dependencies, problematic components
• kitt (theme specs): regions, page template variabls, element attributes
• these are currently working documents based on developer feedback

Distributing Features