Code-driven development

Submitted by on

Reading about development being code-driven on a software developer's blog is a bit surprising, isn't it? As if development was not all about writing code in this industry. Yet some developers use the term to distinguish their method of building web sites with Drupal.

Judging by the top 20 Google search results at the time of writing, the term code-driven development seems to be used exclusively by some in the Drupal community. The only matches not related to Drupal are about test-driven development, demonstrating a lack of other references. Like any community people working with Drupal come up with their own terms for idiosyncratic concepts. However the term code-driven development is misleading and the problem it wants to solve is certainly not unique to Drupal.

Drupal is a breed of content management system for the web that does not require coding skills to customise. Almost every aspect of a Drupal website can be configured through a web UI. An ecosystem of extensions called modules is available and can be added easily to an existing site following the same philosophy. One such extension, the views module, even provides a UI for creating database queries and displaying their results in a highly customisable fashion. All that power is based on storing the configuration that defines the behaviour of a site inside its database along with the content.

Essentially a web content management system like Drupal enables a person, called a site-builder, to define the behaviour of a website entirely through configuration. The way this is achieved has some serious drawbacks though: If development of new features is supported by a team of engineers, distributing configuration changes poses serious challenges. It is not impossible to manage, but it can become tedious work quickly, which might outweigh the advantages of using Drupal over a framework.

A solution to the challenges posed by Drupal's architecture has been pioneered by making use of the notorious Features module. The idea is to export configuration data from the database and put it into a version control system alongside with the source code. Some people in the community call this approach code-driven development. Obviously, putting configuration files into a version control system does not make their content source code. Eventually the Drupal community came up with the right name for the solution. One of the key new features of Drupal 8 is called Configuration Management.

Comments

Submitted by Albert Albala on Sat, 03/01/2014 - 17:58

I find most people who use Features don't take the concept of code-driven development far enough, still requiring database cloning to create a new environment. If you need to clone the database to get your full functionality, then your version control repo is not really complete. I started using the concept of a site deployment module on all my projects of late, making sure there is one master module which, when enabled, contains everything necessary to make your site unique: features, but also the default theme and all other configuration which is not exportable by features (for example removing the "Powered by..." block, etc.)

Submitted by John_B on Sun, 03/02/2014 - 12:43

Drupal was built primarily with site builders in mind, and this is one reason config. is in the database (which is also true of Wordpress, massively the most successful CMS on the planet). Drupal professionals often say 'if you are not using Features you are doing it wrong.' They are missing the point. It may be because the people who are wirting about Drupal are the minority who are using Drupal for larger sites which it was not really designed for. Now Drupal 8 is made for larger sites, probably because that is where the money is for companies like Acquia and other large Drupal shops with high-level skills. However, central to the concept of Features is the idea of taking a large hammer and trying (with only partial success) to beat Drupal into a different architecture than it was desigend for. If you want all config in code, Drupal 7 is the wrong tool, and historically Drupal was never conceived for that type of use case. Drupal 8 is different of course, and if it works as well as we all hope, it will be right tool for makers of large websites (although whether Drupal with CMI will still work for the vast majority of amateur and small-time professional site-builders which Drupal served so well in the past is an open question).

Submitted by Adjuno on Tue, 01/17/2017 - 01:13

Well drupal is good but most developer now focus on wordpress development which is powered by CSS easy to design, as well as with premium plugins are free.

Submitted by on Tue, 01/17/2017 - 14:06

One reason I stepped away from Wordpress is that the plugins are not all free and it is a bit dodgy how they let you know... you do not find out some plugins cost money until you have already installed it and you see the 'trial version' notices... That's not nice.

Add new comment