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.
Save to - del.icio.us - Digg it - reddit - StumbleUpon - Twitter Short URL: http://sachachua.com/blog/p/5009
Hi,
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 http://www.drupal.org/project/deploy 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 http://www.drupal.org/project/deploy, maintained by heyrocker. I did also some exploration into that direction, the result is port module and lives in my sandbox: http://cvs.drupal.org/viewvc.py/drupal/contributions/sandbox/alex_b/port/ – 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 -
[...] Windows-based PHP developers on my team, I updated the web-based deployment script I mentioned in Development kaizen: deployment and testing. I added the ability to push a specified revision to the production server. It took me less time [...]