December 4, 2008

Bulk view

Drupal, Makefiles: save time, make awesome

One day I’ll post a generalized version of the Makefile that makes my Drupal life so much easier, but in the meantime, here’s the general structure I use:

  1. Lots of configuration settings:
    DB
    Database name for Drupal site
    DB_USER
    Database user for Drupal site
    DB_PASSWORD
    Database user password for Drupal site
    ROOT_DB_PASSWORD
    Root MySQL password, used to drop and recreate the database, and grant permissions
    SVN
    Subversion branch for source code control
    SVN_USER
    Subversion user name
    SVN_PASSWORD
    Subversion password
    SITE_DOMAIN
    Particularly useful when working with sites that use Domain Access, but handy even with other sites because of BASE_PATH
    SRC_DIR
    Location of source code, needed for Drush
    DRUSH
    Drush command line, just in case I want to fiddle with it
    DB_PREFIX
    Database prefix, for make clearcache

    BASE_PATH
    Base URL

    DRUSH_GROUPRE
    Regular expression to match against simpletests using my modified Drush_simpletest that lets me run all groups of tests matching a regular expression
  2. An include statement
    -include *.mk
    This is really useful. This lets you override the variables using a file like local.mk, dropped into your current directory and kept out of your source code control system. I use this to make my Makefile just Do The Right Thing when it’s in different directories or on different servers. Do not forget to tweak your included file (or make sure there is one) if you need different configuration settings.
  3. Lots of targets:
    backup
    Uses mysqldump to back up the database.
    restore
    Drops the database and restores it from the backup.
    clean
    Drops the database
    install
    Calls the site’s install.php with the appropriate profile.
    cron
    Calls the site’s cron.php
    mysql
    Starts a MySQL connection to the Drupal database. I don’t have to remember what the database name is or what the connection details are, hooray!
    clearcache
    Clears the {cache}, {cache_menu}, {cache_views}, {cache_content}, {cache_filter}, and {cache_page} tables
    revert
    Hits the panic button and reverts my tree. (because svn revert . -R is too long)

    tags
    Regenerate the TAGS file that lets me find function definitions really quickly
    test
    Use Drush to run all of my simpletest functional tests for this project

Sometimes I’ll have an “rsync” target to deploy files to a server and a “doc” target to regenerate my low-level documentation using doxygen, too.

This Makefile is seriously cool and seriously time-saving because it means that no matter which project, branch, directory, or server I’m working on, I have a consistent set of commands for the most common things I need to do. The less time I spend thinking about fiddly administrative tasks, the more time I can enjoy in the coding zone.

This is also one of the reasons why Drupal development is _so_ much easier on Linux or other Unix-ish systems, or even Microsoft Windows with the Cygwin environment. If you see yourself doing a fair bit of Drupal work, it’s well worth investing the time in setting up a virtual machine or a second partition, learning a new operating system, and re-setting-up your development environment.

make awesome. =)

What’s in your Makefile, or what other tricks do you use to increase your developer happiness?

Drupal rockitude

I joined my current Drupal project two weeks ago after documenting and wrapping up my other Drupal-based project (which I’m happy to report is chugging along quite nicely without me). Since then I’d been quickly going through my task list. I’ve also been poaching other people’s tasks, such as the configurable group home pages and the deployment scripts. As I told my cat, I’m having fun rocking Drupal. ;)

Today, one of my project team members demonstrated the site to members of the other consulting team. He wasn’t sure if the reception would be neutral or even hostile. He walked through the various features we’d built in two weeks of work, a short period of time that included the numerous issues other people encountered and my ramp-up time as a new member of the team.

One consultant from the other team couldn’t help but say, “Wow.” And the rest of the team really liked it, too!

So I guess I can count that as my first “melting a tough client” story. =)

What worked well?

  • Even though I was new to the team, my team members gave me plenty of latitude in building tools and reorganizing things. There were a couple of changes that we needed to discuss, but usually, the practices I suggested made things a bit easier and the changes weren’t difficult to get used to.
  • I set up my local development environment (my uber-tricked-out Emacs) to make it easy for me to quickly shift between files in different branches of code, look up definitions of functions, and re-build the site.
  • As a lazy programmer, it’s in my best interest to automate as much as I can. I kept tweaking the build process until I could get it to work without manual intervention, and I plugged it into the web-based deployment script I’d written for my previous project.
  • I reused as much as I could, relying on a combination of grep, var_dump, printf, tags, and asking coworkers what’s responsible for what.
  • Also, starting work at 5:15 AM turns out to be pretty good for me. I get almost a full day of work into the morning, I can spend a little time in the afternoon attending to things that require less creative energy, and I can even take a short catnap in the afternoon sun (complete with purring cat!).

I’m looking forward to tidying this site up, and I’m sure I’ll have lots of fun getting the next site off the ground, too!