Problems with Drupal and version control.
There is one staple of team-based development that Drupal unfortunately falls miserably short on: version control. Mariya Lysenkovain outlined perfectly many of the reasons why Drupal sucks, and again in her follow up article. Among her reasons she mentions how Drupal stores most of its configuration in the database. But so what? What does that have to do with version control and multiple developers? Actually, a lot. Databases are not shared between developers or environments, nor should they be, so any configuration that is saved on one machine will not be reflected anywhere else. This is a huge hurdle when trying to use version control, and can break a Drupal site faster than 777 permissions on the files directory (gratuitous nerd joke #1).
The Features workflow.
Possibly the most widely accepted workaround for this problem is the Features module, which addresses this issue by exporting almost (emphasis on “almost”) every database-stored configuration setting for a particular site feature into the code of a generated module. These modules then become part of the codebase, and can thereby be tracked by the version control system. Other developers can then update their database settings on their machines with a `git pull` and a simple Drush command. If you don’t know what Drush is, then you’ve probably stumbled across this blog post by closing your eyes and wildly clicking your mouse and mashing your keyboard into Google (gratuitous Drupal-nerd specific joke #2).
Why this won’t work for everybody.
As nifty as the Features module is, it is not without its flaws. The biggest flaw is that this workflow is not how the Features module was intended to be used, so it can leave out important settings that are crucial to the functionality of the feature.
The next inescapable flaw is that every single developer on the project needs to be hyper-aware of this workflow, and be extremely diligent about keeping their Features modules in sync. Developers who are more used to working in a framework like Ruby on Rails are spoiled by things like migrations and testing, and will always raise a pretentious nose to the workflow above. And who can blame them? If a project requires just a few more than one or two developers this workflow would become impossible to manage, and would likely drive the lead developer to the point of homicide.
What it does well.
However, like most workarounds, this workflow has its niche. Using this in a small team can prove to be a huge time saver. If exporting a site feature to code will save a developer even just an hour of work trying to duplicate functionality from their local workstation to the production server, doesn’t that make this process worth it? In a small business or agency the development team doesn’t always have control over what platform a website is built on; the client may have the final say. While this isn’t an excuse to write off poor decisions, it never hurts to make the best of any situation. And if Drupal is the platform of choice, this is a workflow worth acknowledging, if only just to keep the lead developer out of prison.