Riding the override

People familiar with website development will be aware of the need to transform the configuration stored in the database to code, which can be added to a version control system. It is a prerequisite for utilising 'pipeline' deployment architecture and obviates the need for manual configuration of a site when it is deployed to another machine.

When developing a Drupal based site we utilise the powerful ‘Features’ module to handle the conversion of site configuration to code. But its use comes with some health warnings. The dreaded ‘overridden’ feature is a condition that can arise when dependencies are missing, if there is a difference between configuration stored in the database and code, or a myriad other exotic reasons. Some of these conditions are simple to diagnose and rectify, but for others the solution can involve hours fruitlessly tearing hair out and banging the keyboard against ones balding head.

At GI we have developed a number of methods for avoiding an overridden feature. The first is to break out distinct configuration, say a blog listing and comment section, into separate features. Developers avoid work on the same pieces of functionality at the same time, to ensure the same site is not configured in different ways. Automated testing alerts us if a commit has left a feature in an overridden state. We utilise the Diff module to discover how a feature has changed during the development process, gaining us insight into its present state.

Employing these techniques has allowed us to override the ‘overridden’ feature, and spend more time growing our hair back.