Development kaizen: Deployment and testing

I got back yesterday to a still-empty defect list, so I decided to spend the day working on some infrastructure to help my team work more effectively.

Thinking about what could make the most difference in the other developers’ productivity, I decided to invest time into making it easier for them to deploy code to the testing server. I had written a Makefile target that efficiently transferred only the updated files, but the other developers worked on Microsoft Windows and did not have all the necessary tools. I spent the morning writing a web-based interface for them: a password-protected PHP script that displayed a list of recent revisions and allowed people to deploy a selected revision to a separate server. Behind the scenes, it was a mess of bubblegum and string. To work around various limitations, I strung together sudo and suid and rsync and ssh key-based authentication. It wasn’t pretty, but it worked. I e-mailed instructions to my team members, and they started using it right away.

After solving that problem, I focused on improving our tests. Fixing one bug often led to creating or recreating another, and these regression errors resulted in back-and-forth communication and wasted time. I explored the Simpletest automated testing framework for Drupal, and found out that I could write both unit tests and Web-based tests using the framework. However, I had a hard time figuring out why several of my Web-based tests consistently failed. I found out that the latest version of Simpletest for Drupal 5 did not understand the Location: header, which we use extensively in order to direct people to different subdomains and external sites. I fixed it and wrote a number of tests for one of our key modules. By the time I was ready to pack up and go home, I’d gotten into the swing of writing test cases.

Easier deployment and automated testing go a long way towards making a project almost a joy to work on. I’m glad I spent some time paving the way for my team and for other projects to come. =) Kaizen: relentless improvement.

One Pingback/Trackback

  • RC


    When deploying, I’m curious to know how you deal with the Drupal database.

    You mentioned that you are deploying to a testing server, so a complete rebuild is probably okay. If it was a deploy to a production server, however, you’d have to deal with incremental database changes (ie: changes to some rows in the variables table), while maintaining user data (like certain node types).

    Figuring out how to deploy Drupal keeps me up at night :-(

    • You might want to check out by heyrocker . I did some exploring into that direction, too. The result is port module (lives in my sandbox). There is some overlap between deploy and port, I’m in touch w/ heyrocker on this. BTW: for the content type ports I took some inspiration of Sacha’s great post on how to create a content type programmatically.

  • Check out, maintained by heyrocker. I did also some exploration into that direction, the result is port module and lives in my sandbox: – port module does a subset of deploy, I’m in touch w/ heyrocker on possible cooperations. both modules support export/import of site portions. Neither of the modules support a good update (as opposed to add) mechanism though –

  • Pingback: Deploying to servers | sacha chua :: enterprise 2.0 consultant, storyteller, geek()