Like mentioned in another comment, upgrading from 2.3.x to 3.0.x is a feat in itself. Upgrading from 2.3 to 3.1 might be doable on a smaller project, but with code written in several versions of Rails we decided to go 2.3 > 3.0 > 3.1.
> Also, shouldn't these simple bugs be quickly and fully discovered by automated tests?
There was plenty of HTML inside Ruby statements in our templates that started being escaped. Something like:
<p><% (price > 10) ? '<strong>Expensive!</strong>' : 'Cheap' %></p>
while ugly was not wrong. This is a very simple version of some of the problems we saw, and there were typically several per template. Writing tests that check the HTML output of template files would be unmaintainable.
> If the upgrade is done on a branch, why must the work be completed during the weekend?
To avoid a big merge. We changed a lot of files and didn't want to have to re-check our work after letting Git auto-merge our changes.
They switched to 3.0 quite some time ago:
> Our production instances made the final switch in the week leading up to Thanksgiving
Writing this blog post probably wasn't very high priority.
> How did this happen?
Maybe they were busy creating a great product instead of obsessing about perfect architecture and optimising prematurely?
I think you'll be hard pressed to find anyone who believes that ensuring all of the servers are running the same code is a 'premature optimization'.
Do you actually believe this?
Tests are a nice first pass, but they'll never fully discover every bug -- especially with a huge change like this.
Edit- left out a word
> Clone the rails3 branch into a separate directory from the usual working directory (instead of simply switching branches)
What does this accomplish?
Air BnB haven't been in the news for awhile and sales have been slumping, so they coughed up this hairball of a post to stay "top of mind".
Title Upgrading Airbnb from Rails 2.3 to Rails 3.0
Date January 4, 2012
Why are you blogging about upgrading to Rails 3.0.x when the current stable Rails has been 3.1.x for over 4 months?
> Our app was running Rails 2.3.8 at the time, and the production instances were a mess. Each instance had its own set of gems and its own versions of those gems. Naturally, none of the instances matched.
How did this happen?
> Tobi listed every controller in our app at the time and divided them among the engineers. The engineers went through the templates used by each controller and made sure string output in templates was marked as html_safe or rendered with raw where appropriate.
Most of the XSS work was done in a single day with all of the engineers' help, but there was cleanup on pages that weren't used very often that continued for several weeks after installing the plugin.
Why look at the controller granularity for templating bugs? If any controllers share a partial or helper, you may have engineers stepping on each others' toes.
Also, shouldn't these simple bugs be quickly and fully discovered by automated tests?
> We knew the real upgrade required major code changes, so four engineers started the upgrade on a Saturday afternoon when there were minimal changes being committed. We asked other engineers to hold off on changes over the weekend to prevent any merge nightmares.
If the upgrade is done on a branch, why must the work be completed during the weekend?
And why must you block changes generally for an entire weekend because of work done to a single branch?