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. ;)