Filed by Phil at 9:27 am under Uncategorized, Drupal

Much like tax professionals, we’ve been very busy here at WGBH these last few weeks! As the kids like to say, here’s the 411 on all that.

Our good buddies in the WGBH IT department (note: always make friends with the folks in the IT department) have installed and configured several new servers for us! It’s like Christmas came really early (or very late). Here’ what we found under the tree:

Code Repository

We’ll be using Subversion (SVN) to manage our code base. We’ve now got a stand alone server for this repository. Currently, we use CVS (the concurrent versioning system, not the drug store), with a repository piggy-backing on our current development server.

Development Server

We’ve got a new development server that’s now running PHP, MySQL, Apache, phpMyAdmin, SVN (client), CVS (client), etc. and so forth. As the name suggests, this is where we will do all of our development work. More on that below.

Test Server

We’ve also got a new test server, that will be used as a staging area for proper QA. Software installs will mirror those on the development server. This will replace our current test suite, which consists of separate web and database servers.

Now that our new development server in place we can really plow forward with development of our new TV Programs and Schedules module. It also means it’s time to make (and implement) some big decisions. Allow me to elaborate.

Drupal Version

As I mentioned earlier, I was holding off on making a final call on whether to build on Drupal 5 or 6 until the new development server was up and running. Up until now we’ve been doing preliminary coding on a Drupal 5 install. Well, after doing some reading, soul searching, chatting with my religious counselor, etc. Pete and I have come to the following decision:

We’re going to go with…

(drum roll, please)

Drupal…

(more drum roll)

version…

(dramatic pause)

6!

I made this call after looking over the state of major contributed modules that we would need to proceed. These include (among others): CCK, Date, Devel, FeedAPI, Image, Image Assist, Pathauto, and Views. It seems that all of these modules (except for Image Assist) have at least a development (or alpha or beta) version that works (to some degree) with Drupal 6. The big holdup here seems to be the completion of Views 2, upon which much depends.

Our thinking is that it’s better to suck it up now, live with the Drupal 6 growing pains at the outset, and end up with a site on the latest version of Drupal, before the next major release early in 2009. If we build on 5, we’re looking at launching a site on a version of Drupal later this year that will quickly be two major releases behind. Also, Drupal 6 just has lots of nice improvements that we’d like to take advantage of. Or should it be “of which we’d like to take advantage?” Wish I’d paid more attention in 10th grade English class.

So, we’re going with 6. No worries, no regrets. No pain, no gain. I’m out of cliches.

Development Environment

How Pete and Josh and I (and maybe others) will be developing the new site is, clearly, an important thing to think through at this point. We want to set up an environment that allows for the most efficient development, while also being easy to use, secure, easy to push out to new developers as well as staging and live environments, etc. Lots to think about.

Here’s the plan.

All development will take place directly on the development server. Since none of us travel much, if at all, we don’t have much need for working locally offline (like on an airplane). By developing directly on the server, all we need is Internet access and a VPN connection and we can go to town. Each developer will have his own database and copy of the site code (or possibly more than one of each, if need be). It will all reside on that server, which makes backup and maintenance easier.

As mentioned above, all code will be managed using SVN. Core Drupal code and contributed module code will be downloaded using CVS from the Drupal CVS repository. This code, along with our custom code and any changes to code or module code will be tracked locally in SVN. Developers can get code updates from others using SVN updates. Nice and clean and easy.

Code will be rolled out to the staging and live versions of the site using SVN. We will not be doing any commits or code distributions on an automated basis. One tricky aspect here is the propagation of setting/code/content stored in the database to other developer installs or staging or live environments. There is no easy solution to this well-known problem. Initially, our approach will be the following:

• Create a WGBH.org installation profile - This profile will be used when rolling out a new developer environment or when initially setting up staging and live installs. This will enable the required modules (both core and contributed), set certain variables, and create base users and roles. I’d like to keep this profile small, since we won’t be using it all that much. This will need to be maintained over time as basic changes are made to the site.
• Use custom module install files - We will use custom modules for (among many other things) managing database changes (both DDL and DML). So, for example, our custom TV Programs and Schedules module will have an install script that creates a number of CCK content types, populates some content nodes and sets some additional database variables. As development proceeds, this file will also be used for making required database updates to existing installations. We will do a similar thing with other custom modules as the greater site rebuild proceeds. This should help to modularize the maintenance of all of the various database setting, objects and records.

At least that’s the theory.

There you have it. Now, if you’ll excuse me, I have quite a bit to do…

P.S. If you have kids, Horton Hears a Who is excellent! I highly recommend taking the little ones to see it. If you don’t have kids but enjoy hallucinogenic drugs, I’d wager you’d also enjoy it quite a bit. Just a guess.