Introducing #codepower

Building a website using Drupal is essentially about tuning and extending its core functionalities to meet the project's specific requirements. During its development phase we create content types with CCK, display them using Views and extend the basic functionalities by setting up contributed modules. All these actions are recorded into the database in the form of a very heterogeneous collection of settings, each specific to the module it belongs to.

When the development phase is completed the database probably contains, besides all our valuable configuration, other Drupal "entities" such as content, users, etc... that we don't really want to carry along once the website goes live: a careful and time consuming cleanup is then necessary.

With time our website naturally grows in size; it contains much more content and several users are active on it: soon it might be necessary to extend its functionalities. How to do it when both settings and content are now valuable, when really nothing can be lost during development?

The immediate solution could be to work on a copy of the production database and restore it afterwards. This, obviously, means that activities on the production website have to be suspended until the new development is completed. Additionally, a pre-live clean-up will probably be necessary also in this case.

When a team of developers works on the same project issues multiply: if each developer keeps and works on his own database dump the risk of overriding each other's changes is high. Another option is to work all together the same shared database, but still hoping that nobody will mess things up.

It is clear that relying on the database makes the development flow really error prone, not easily scalable and definitely difficult to maintain.

Settings in code: the key to Drupal heaven

Keeping track of changes, working concurrently on the same project and resolving conflicts are all issues that are usually addressed by the adoption of a version control systems (VCS). Unfortunately they are not that useful when it comes to working with configuration stored in database: you can surely version a dump but change tracking and conflict solving are practically impossible.

Everything changes if configuration is stored "in code", meaning that, instead to have settings spread across different tables, they are translated to understandable PHP code that Drupal modules can easily consume. Exportable entities are not something new in the Drupal universe: modules like Views and CCK have already supported exporting setting for quite some time. What's missing is to streamline the export/import operations to, eventually, switch from a database to a code driven development. All this is today possible thanks to the Features project. This project introduces the concept of feature as a collection of settings and configuration that describe a very well defined functionality. In doing so it implements a very solid system of keeping track of changes that occurs to settings "owned" by a particular feature making easy to dump them to code. That's basically it, the rest is all about wisely organizing our project in features which keeps all our settings safely in code. At this point, by using our favorite VCS, changes get traceable and conflicts resolvable, exactly how it happens with standard PHP code.

Introducing #codepower

Projects like Features, Chaos tool suite or Strongarm are at the heart of the code driven revolution, even though a lot still depends on how actually we are going to use this technology: good code conventions, well defined features boundaries and other good practices can really make the difference, at the end of the day.

What we really need is to share each other's best practices to develop together patterns for a solid code driven development. For this reason Nuvole introduced, at Drupal VolCon in Antwerp, the #codepower Twitter tag. The idea is simple: we will tweet and tag with #codepower whatever we deem interesting to be shared with the community regarding code driven development. We ask you to do the same.

The Movement

Today we all have the chance to push Drupal even further by changing the way we work and develop applications with it. At Nuvole the adoption of a code driven development has completely revolutionized our working flow, making it more maintainable, solid and scalable. For this reason we want to contribute back to the community our experience about code driven development with a series of blog posts, starting in occasion of the first event on the matter: "Developer Session: Code Driven Development", the 27th of May 2010, in Antwerp (Belgium) hosted by the great guys at Krimson.

Tags: Code Driven Development, Drupal PlanetImage: