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?