Drupal, Deployment and You!

I've been working with Drupal in a professional capacity for about seven months now, and I have to say that the biggest hurdle for adoption I am seeing is the inability for Drupal to gracefully deploy from development to staging to production servers.  This is something I've been struggling with for months now, and with my current project being as large as it is, and having multiple developers, all working from different sandboxed environments, as well as multiple staging servers for both in-house and client review, this is becomming a huge down-check on using drupal for further projects.

I've been told to use the Features (http://drupal.org/project/features) module.  At first glance this appeared to be the solution I was needing.  I have approximately fifteen content types and 50 or so field definitions from CCK that need to be kept in sync.  I have almost two dozen roles that need to have permissions managed, not to mention numerous views, pages, page variants and other sundry information that is kept in the database traditionally that needs to get synced as well.  After the first blush I began to realize that Features really is not meant for those of us doing large scale custom module development.  Yes it gives you a nice little package that contains all your data, but I kept running into problems with getting the dependency chain right, not to mention the constant feature update/feature revert cycles I'd be contending with (which, sadly enough, did not always work).  I'd end up with missing or circular dependencies, no matter how I would try to break up the feature modules.  If I did something that was pure Drupal configuration, with little to no custom code, just a collection of pages, content types and views, then features would be great.  It seems to struggle and even outright fail when you are trying to package information in support of a custom module, or modules.

When I discovered I was spending as almost as much time managing the features as I would have spent manually clicking the interfaces or 4 or 5 separate sites to keep them all configured I went back to the drawing board to try to find a better solution.  After spending hours googlling around, finding site after site that have nothing further to say on the topic than "Use Features!  It's cool!", I stumbled on some information about how to use the built in export function of Views to store your views as code within a custom module.  There were also hints that this same technique, with a couple of modifications could be used to manage pages and page-variants in the same manner.  This was more difficult to find, namely because while the interface terms them as "variants" page variants are called "handlers" in the code.  That little bit of inconsistency cost me half a day to track down.  I finally got help on that by encountering one of the Chaos Tools maintainers in IRC and asking the question there.  Once that bit of inconsistency was ironed out, getting pages and variants to play nicely fell right into place and after about 30 minutes of work, all my views, pages and variants/handlers were embedded into the module itself and playing very nicely, pushing from server to server and just needed some reversion love to do the updates.

(As a side effect of this, it was trivial during a client demo to make the changes to a given view right in front of the client, knowing that afterwards I can export the code and update my development system with the changes, and knowing that I wont have to worry about it as they migrate back up the chain.)

I am planning on a series of posts as follow ups to this one to lay out my methodological madness in making all this work.  I will start with the easy case, Views, and move on from there to pages, variants and eventually to content types and CCK fields (though not sure how this one is going to work yet, as I havent found a good way to make it happen).  I still plan on using the Features module to manage the Sisyphean task of managing my roles and permissions for now.

My major hurdle at this point is to ensure that all my views and pages are being handled in the right manner, and getting rid of all the scattered Features modules I have managed to swamp my sites/all/modules directory with in my attempt to make my life easier.

Next up:

• Views as Code