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.
I can hardly believe it, but it's been almost three years since I wrote the original VPS! Getting Drupal up and running on a linode article. These days, I'm still with http://linode.com, where a lot of my clients end up hosting their web app sites; and I'm still installing everything by hand, which is still the best way in all but a few cases, since it gives me what I came to a VPS for in the first place: control over what's going on, and avoiding locking myself into immediately obsolete schemes unless I choose to do so. Of course, there are some excellent install scripts, which Linode calls Stack Scripts, with many of them dedicated to getting Drupal up and running in a variety of excellent manners, even including Pantheon Mercury and Aegir turnkey "single click" scripts. Certainly a great way to go in certain alternatives.