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
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 [...]