Feature Hats

Despite the title, wunderkraut has not yet branched out to hatmaking:
The "feature hats" we're talking about is our approach to minimize conflicts when using a code-drive development method for Drupal, especially when using Drupal features for storing configuration in code. This configuration is changed by developers by updating features, i.e. exporting configuration in code via the popular features module – a merge-based source code version management alone like git doesn't avoid confilcts here.

The typical code-drive development approach for Drupal 7 involves a combination of an installation profile, exported features, a modern version control system like git and a good use of branches. In this setup, a central development server is optional, and if it is there it is only used for testing purposes. No configuration changes are ever done on a remote server. Every developer has his or her own local development environment and changes are exchanged exclusively via git. All contributors to the project use this workflow, whether they are site builders, themers or hard-code developers.

The features module plays a key role in this setup, but it can also lead to conflicts when two developers work on the same component and change configuration locally which is then exported in code via features. In short, two people simultaneously override the same feature component in their local environment, and whoever exports their change last completely erases other people's changes – or git simply merges the changes together, so the feature appaers as 'overridden', since its git-merged code would've never been generated by the features module. As you can guess, such problems have a tendency to work against an efficient collaboration.

The solution is of course to only have one person working on one feature at a time. Our "features hats" method is just a formalized version of asking around the office "Is anyone working on the feature 'myproject_user_profile' ??? ", with the advantage that it works with distributed teams: A "feature hat" determines who is currently working on a feature, by assigning a "feature hat" ticket to this team member. As with a real hat, only one person can wear the hat at a time. The theoretical hat can be materialized as a ticket in your project management tool. When you start working on a feature, you first check that the "hat" ticket is not assigned to anyone. You are responsible for checking that the feature is in a default state (relative to the master branch) whenever you assign the "hat" ticket to yourself or when you are done with your changes and unassign the ticket from yourself (Bonus 1: You can get a complete overview who works on what features within a split second; Bonus 2: Your ticket system tracks who worked on which feature over time).

While this system seems like a simple extension of common sense, it can save a lot of time in the development of a project. By combining these feature hats with a git rebase workflow, we have been able to reduce the occurrence of conflicts with feature code to almost zero.

Want to try this for yourself? Just create one "hat" ticket per feature in your task-tracking system (we use redmine), and you'll be ready to go!

Feature hat ticket and subtickets in the issue list.

Feature hat ticket (single view), with subtickets and description.