Everybody uses Features, but using them properly makes a big difference

Nuvole built some respectably sized projects in 2011: a few large international projects (including a heavily customized Open Atrium installation for Higher Education experts and a portal for collaboration between Europe and Latin America on educational matters) and a bunch of ordinary websites, besides our other activities such as trainings and general consultancy. And people occasionally ask us how big Nuvole is.

Well, the truth is that Nuvole is a two-people company, helped by minor contributions by external consultants. Yet, it manages to run and maintain sizeable Drupal projects by using Features -the easy part- and by doing it properly - the hard part, and the main focus of our DrupalCon Denver Training.

So the key is not how many people work on a project, but how efficient their workflow is. Adopting a Features-based workflow provides a solid basis, but you still need to take a lot of design decisions: some will be easier, some will require a bit of thinking, some will prove correct or wrong only months later, when the project needs infrastructural updates.

Nuvole pioneered a Features-based development, and what in general we call the "Code-Driven Development workflow", a couple of years ago. Our Features-based projects look much different now: we found out that our old structure was not optimal, or that technology allowed for cleaner workflows (Drupal 7 brought some substantial improvements, for example). We structured our new projects to take the new knowledge into account, found new challenges and gradually solved them.

Here are a couple of examples of the design decisions you will be happy to have taken properly (we will cover them in detail in future blog posts).

Hard and soft configuration. A site, especially when built as a distribution, should ship with complete pre-configuration. And this pre-configuration should be in code, we don't want to carry a database around. But should all of it go into Features? No, because some pre-configuration (the soft one) is meant to be overridden in the normal site customization, while Features should only contain the hard one, i.e., configuration that defines the site structure. The soft configuration (like the default site title, or default colors) is best handled by putting the corresponding code in the installation profile rather than in Features.

Feature separation. When all your site configuration is in Features, you quickly realize that it is not feasible to put everything into one Feature: you will need multiple Features to build a website, and this means you will have to take decisions on how to split your site functionality across Features. A common mistake is to build transversal Features, like a "permissions" Feature with all site permissions: this works, but it introduces annoying interdependencies and maintenance difficulties in the long run. The problem is best solved by basing Features on content types, thus making them truly modular: in general, a Feature should contain a content type and everything that is related to it, such as views, contexts, image styles and permissions.

The Nuvole DrupalCon training, Code-driven Development: Use Features Effectively, will be held on March 19th, the day before DrupalCon Denver. The training is open to both DrupalCon attendees and externals, and must be booked from the DrupalCon registration page.

Tags: Code Driven Development, Drupal Planet, DrupalConImage: