Rapid Feedback
(Sun May 22, 2005) [/Rails] #
One of the most rewarding things about building a Rails application is the constant and rapid feedback you get along the way. There's no noticeable friction between making a change and seeing it in action in the browser. That makes for a feedback loop that's both fun and highly addictive, and yet it also has tremendous business value. The folks paying for the work get to see results early and often, and in return you get feedback from them to help you optimize the next move.
Yesterday James and I finished up the first task that's demonstrable in a browser: single sign-on. At that point it was time to call our customers over to kick the tires. There was just one problem: we all live in different cities. OK, so it's not really a big problem since we're building a web application. It just needs to be hosted somewhere convenient for everyone to see. No worries; we have a test server for that.
Ah, but pushing changes up to the test server will introduce friction in our process. And why settle for synchronizing changes with the test server only after we've completed a feature? Better yet, why not let everyone see what we're doing all the time? And before I could say "Automate!", James had whipped up the following Subversion post-commit script and had it running on the test server:
#!/bin/sh REPOS="$1" REV="$2" `dirname $0`/mailer.py commit "$REPOS" "$REV" svn update /Library/WebServer/Rails/SuperSecretProject
Whenever we commit changes in our local workspace, the post-commit script runs and updates the project directory from the Subversion repository on the test server. It's in this directory that WEBrick (the development web server running our Rails application) is watching for changes. The next time someone makes a request to the Rails app running on the test server, WEBrick automatically reloads the changed files.
We may need to smarten up the post-commit script in the future to handle changes that require a restart of WEBrick. And I'm sure we'll slip up at some point and check in something that causes bad things to happen to the application up on the test server (another form of feedback). But in the meantime, this seems to be working pretty darn well. We get local feedback by writing code, running tests, and using the app on a local web server. When we need feedback from the team or just want to checkpoint our work, we simply check in the changes. Surprisingly, we rarely go more than a few minutes before checking in.
