Kaizen: What would make our Drupal lives better?

Kaizen: relentless improvement.

We’re getting ready for the next phase of our Drupal project, and it’s a good time to think about how we can make our process better.

  • Automated builds: I have a few Makefile commands related to pushing the latest development source code to the testing server, but the other developers can’t use the commands on Microsoft Windows. However, they have access to another Linux-based server. If I can simplify the deployment process (maybe a password-protected webpage that allows you to choose which revision to deploy?), then they won’t be held up when I go on vacation.
  • Automated testing: We used simpletest for a few pieces of functionality, but we don’t have anything close to coverage. I’d like to learn how to write proper tests for Drupal so that I can avoid regression errors, which I often made during development.
  • Switching between hosts: Because we use Domain Access, I can’t just use a local domain name and a copy of the server’s database. My current approach is to use the same domain name as on the testing server, and then keep editing /etc/hosts to switch back and forth. An alternative might be to create a Makefile target that grabs the server’s database, runs it through sed to translate all the domain names to my local domain, and restores the database from this translated file. That way, I don’t need to edit /etc/hosts all the time.
  • Coding environment: I’m thinking of moving my development from Eclipse to Emacs in order to be able to customize my environment more effectively. I’ll post more notes about it as I figure out what works for me and what doesn’t. It’s a good excuse to learn even more about Emacs…

What worked well:

  • Source code control, I love you so much, even if you’re Subversion.
  • Adding a CSS person to our team meant that the other developer and I were much less stressed out about cross-browser issues. Hooray!
  • Using a defect-tracking system was infinitely better than sending e-mail around, even if that defect-tracking system was ClearQuest. ;)
  • http://homeworldfan829.livejournal.com joedwebguy

    Hi,
    I’ve been reading your blog, and noticed the drupal entries.

    And I couldn’t help wonder just how great it would be if you were to join our drupal org group for the Philippines @ groups.drupal.org/Philippines.

    Please join us! We’re just about starting to try marketing drupal and probably try start our own Drupalcon, hopefully!

    Best Regards,
    joe

  • http://ken.therickards.com agentrickard

    Re: Domain Access.

    What do you think we can do at the code level to make that transition process easier?

    I would encourage you to file an issue detailing what you need.

    – Ken

  • http://raygunrobot.com/ Garrett Albright

    You may find the Pathologic module handy when moving content between production and live servers.

  • http://randell.ph/geeky/ randell

    Hey Joe, good thing you mentioned that group. I thought there weren’t any Drupal groups here. I joined just now. And yeah, it would be great to have geek goddess Sacha in that group.

    OT: *waiting for that emacs book* Go Sacha!

  • http://blog.boombatower.com boombatower

    What specifically do you think the SimpleTest framework is missing? Make sure you take a look at the latest 7.x head development in core.

  • http://growingventuresolutions.com greggles

    I encourage you to use the Drupal Project module to power your defect tracking. First, it’s in Drupal. Second, if you find/fix bugs and provide the patches back upstream then you’ll be helping the codebase that runs drupal.org

  • http://ken.therickards.com agentrickard

    I just realized that this patch http://drupal.org/node/284422 can solve your DA problem.