See also Features on drupal.org

  • Jeff Miccolis & Eric Gundersen - Development Seed, building a lot of products (things like Open Atrium)
  • Drupal is very configurable - but that's also a weakness: no distinction between what's configuration (views settings) and what's content
  • Workflow problem: when you build a site, you build in a dev environment, but client/boss wants to see what it looks like before it goes live
    • So, you stage it somewhere, then move it over
    • Development: where the action happens (possibly your laptop)
    • Staging: where it's reviewed (much closer to where it's going to live)
    • Production: where it's live. (developing on the live site is always a bad idea)
  • Three people working on a project that needs to go live
    • Musician, developer, themer
    • Round 1 goes great - everyone works together and the site goes live
    • Round two is a PITA: new views build on dev, rebuild on staging, rebuild on dev, rebuild on staging, over and over, rebuild on prod
    • Extensive note taking, prone to human error, loads of repeated tasks
  • The solution? Make a distinction between config and content - views and settings are heavily and clearly distinguished from the actual content - then write this configuration to code and get it out of the database
  • You can do version control with your config - this lets you track changes
  • Node types, CCK fields, menu, blocks, views - these are config
  • You can say "these components taken together define a feature" - something the site does
  • "Features" module - Feature = Drupal parts that do something specific (Views, ImageCache presets, content types, fields, etc.)
  • Features = Drupal module that allows for the capture of configuration into code
  • (Sorry about the name; the Feature module makes Feature modules which have things)
  • Feature modules have Core exportables: content types, permissions, input filters, menu items
  • Contrib support: contexts, views, ImageCache, Ctools (panels, feeds, etc.)
  • Features is a system to capture the various components that describe how your site behaves
  • Features should be used throughout the development process - you can take a live site and capture existing features, but it requires you to change your thinking about how users interact with the site
  • Concepting what's part of which feature, what's shared, etc. gives you stronger features

Making Features

  • Create a Feature: you can add components, cycle through various elements, clickthe ones you want in your module
  • Features come as a nice tarball - turn it on in your website, you get all the stuff that comes with it
  • But then people start changing the view - you can see the status in the Features module (has it been changed?)
  • If something has been changed, it'll show you what
  • "Recreate" button will give you another tarball, with the current state of things

Create, Update, Revert

  • Drush commands - features, features export, features update, features revert
  • Views changes are made only once, each change has a commit log, if you check it into SVN like you should
  • If you move your development to a real dev environment, and leave the staging site as a staging site (that you can show clients, etc without worrying it broke in the last five minutes) this is good

Distributing Features

  • Are your features appropriate for drupal.org?
  • Is the configuration an IP issue?
  • How can I get that nifty update status thing behind the firewall?
  • If you can't/don't want to send it to drupal.org, but want to manage it internally over time: Features server
  • code.developmentseed.org/featureserver
  • Create projects, make new releases, subscribe to updates, etc
  • For automatic packaging, try the Project module
  • Feature server is much simpler, lets you get off the ground fast
  • Based on implicit standards: update status xml, exportables, drush make