Planning for a Big Update That Should go Unnoticed

Two weeks ago, the end of life for Ruby 1.8.7 was announced.  This affects several of the applications that I work on – in particular Conductor.  About a year and a half ago, I began the process of updating Conductor to Ruby 1.9, but the update was less than smooth.  There were several libraries that I was dependent on that were not yet updated.

I would love to have helped update several of these libraries, but my time is finite, and I’ve gotta keep the trains running.

So I waited.  And this past week, I decided it was time.  I spent about three days running my tests and fixing what was broken. Mercifully all but one of the libraries that I was working on had been updated. Thank you Open Source Community for working on these libraries.

I decided to update the one library myself.  The change was relatively small.  And eventually, all of my tests were passing.  However, I want to make sure that the version update changes had no impact on the public facing webpages that Conductor manages.

So I wrote another script that executes the following algorithm:

  • Given a list of sites and associated URLs for that site
  • Download the site’s templates
  • Fire up a local webserver with the Ruby 1.8.7 branch
  • Request the site’s URLs against the 1.8.7 branch and store the results
  • Fire up a local webserver with the Ruby 1.9.3 branch
  • Request the site’s URLs against the 1.9.3 branch and store the results
  • Compare, using the UNIX diff command, the results of the 1.8.7 and 1.9.3 branches.  If there are any non-whitespace differences between the two result sets, then investigate.

In this way, I can be reasonably confident that my changes have no impact on the front-facing look of the hosted websites.

Take a look at the source code of the script to see the algorithm in action.

I’m going to update the script to crawl through the various GET requests on the admin, to verify behavior.

Comments are closed.