Towards a straight up Drupal development workflow for the working stiff – can't we all just follow industry standards?Fri, 2010-11-19 11:28 — victorkane
I need to write an installation profile for Project Flow and Tracker in order to publish it right on http://drupal.org so that it can be contributed to the community. My goal however is to avoid coming up with one of those monolithic install profiles whose drupal core or modules and themes you can never update on your own without breaking everything, whose functionality you have to take as is on an all or nothing basis, and which is generally speaking unmaintainable and has to be replaced en bloc (sometimes en bric) whenever there is a new release (i.e. erase everything, copy in the new release, run update.php...).
The promise of Contexts and Features driven development was that you got to develop incrementally with everything in code (modular, versionable, automatically buildable), then with the help of Drush Make and the Install Profile API you could make a modern installation profile which simply installs the features and their dependencies, and reverts them to make sure they are properly enabled. And that this cycle can be repeated transparently as the app evolves, as part of its development workflow.
But the reality is that features are the coolest thing in town, but once you knock on that mistress' door, you are imprisoned in her magic forever; and you don't wind up with reusable self-contained components for all your pains. In this article we are going to find out why that is and come to some conclusions as to what can be done about it (under the circumstances). I will present the problem and share conclusions as to how best practices can best be approximated in Drupal app development, and will illustrate conclusions I have come to as to the most sustainable method of creating an installation profile in the context of an ongoing application project.
I touched on this recently in Features driven development -- the nitty gritty and thoughts on the future of sustainable "in code" development, but now I want to systematize my ideas and figure out what to do about it.
The most important thing to consider is that Features as development workflow breaks a fundamental law in Software Developoment:
Software development law #1: there is no one-to-one relationship between use cases (features, functional requirements, user stories, etc.) and project configuration artifacts (modules, themes, menus, blocks, panels, settings, etc.). A single project artifact will serve as part of the implementation of many use cases; a single use case will be implemented in many project artifacts.
Project Flow & Tracker "Chicago" ready for basic use and download - Status update for mid-November 2010Wed, 2010-11-10 11:06 — victorkane
Now close to "Chicago" release candidate and more usable than ever, the Project Flow & Tracker project has been made public and promoted to front page so you can browse the read-only functionality. I believe browsing from business model to roles to user stories to constituent tasks and back again is the best way (in theory and in practice) to understand what has been achieved at this point.
Much greater usability has been achieved, which is something that will be receiving a great deal of attention as a jQuery based UI layer is implemented in the next phase.
Deploying content from a staging server to the live site is important: that's the first thing you learn when you actually start using a Drupal site with any significant traffic, that editing a live site with traffic is hopeless. A couple days ago I showed a simple example with two brand new sites (one staging, one in the role of "live"), installing the deployment module in order to have node operations and references carried out on the basis of a once-in-a-lifetime-assigned UUID rather than its arbitrary node id (the arbitrary nid assigned if you say export and import nodes using the otherwise excellent Node Export module). But what if you now realize that you need this after the site has already entered production? This article reports back upon attempting to do this with the literary workshop example published in my book, Leveraging Drupal.
With Drupal 7, drupal.org re-design, and all the "awesomeness" and hot source and the full pantheon of mythical gods on our web application development horizons, Drupal will still always suck if I can't stage content. Actually using an "awesome" Drupal web application over time (and not just developing it) means needing to be able to cleanly export content from one site, with its references, assets and dependencies, and import it into another. Because you can't be editing a live production site, even with as few as a few hundred simultaneous visitors.
Neither can you go around saying you're a "free as in beer" open source wonder child if you have to be a database management genius to arrange for database clusters and database migration (a la whitehouse.gov) solutions for this; seeking the "up" market (large corporations) instead of the "down" market (working stiffs, small and medium businesses, NGO's), like WordPress does, is all very well, but if you have to be a rocket scientist to cleanly move content from one site to another in order to stage content, then maybe we ought to be more honest about the real costs involved in using Drupal these days.
But, enter stage left the Deployment module! It was designed to solve this problem, and to the extent that that is true, then why wouldn't I develop all my sites using it? Otherwise:
"Ceiling cat is watching you perform search and replace node reference id's on the output of node export module content before importing to live site"
This article takes a look at the architecture of the Deployment module, sets up an initial test bed, drafts an initial acceptance test, runs the test and reports back.
Features driven development -- the nitty gritty and thoughts on the future of sustainable "in code" developmentWed, 2010-10-06 09:16 — victorkane
Features driven development in the Drupal sense involves placing code into versionable text files and packaging functionality into reusable components rather than relying on error prone user interface based configuration with scripting stored in the database along with the content rather than in code. It has been a great step forward for Drupal developers. It is simply a joy to once again be able to develop without infecting the code repository with database dump blobs. And to be able to install functionality in multiple servers running different applications irrespective of the content production workflow. But it is not without its contradictions and limitations, which I would like to mention in this article for the sake of discussion. However, while I will propose ideas for a better solution, I am mostly concerned with leveraging development in code right now by finding a comfortable process for using features driven development today, based on the promise of Adrian Rossouw's now classic "Database Is Silver, Code Is Gold" article The Development -> Staging -> Production Workflow Problem in Drupal.