Re:Upgrading GitHub to Rails 3 with Zero Downtime
by reedlaw on Monday September 15, 2014 @08:11PM
(#8322354)
I'm curious how they handled the differences between the Rails 2 and Rails 3 applications once they enabled dual boot. Surely not all of the changes were compatible. In the Gemfile example, there is some conditional logic that loads different gems depending on whether or not they used RAILS3=true. Was the entire codebase similarly littered with conditionals? That seems like it would be quite a mess.
[ Parent
| on HN ]
Re:Upgrading GitHub to Rails 3 with Zero Downtime
by holman on Monday September 15, 2014 @10:32PM
(#8322742)
Lots of conditionals, yeah. This isn't really a bad thing, to be honest; it's far better than maintaining two separate branches. We already use similar conditionals when dealing with feature flags, so it's not really something that feels out of the ordinary in our app at all.
What's more, we found that if there was a file that had a ton of complicated, interwoven logic between the two versions of Rails, it was a clear sign we should see if we could instead backport a Rails 3 or 4 component so that we could nix the entire Rails 2.x-style functionality.
Re:Upgrading GitHub to Rails 3 with Zero Downtime
by why-el on Tuesday September 16, 2014 @05:11AM
(#8323630)
Exactly. I handle API changes the same way at my place (Its an internal API exposed to colleagues only).
Re:Upgrading GitHub to Rails 3 with Zero Downtime
by alttab on Monday September 15, 2014 @08:31PM
(#8322413)
Only temporary and easy to remove. It would be tricky if entire classes/objects/abstractions were missing entirely. This would require essentially reimplementing that part of the code.
For other Rails version changes, for instance, the removal of RJS as a default component in rails 3.1 could require that you re-architect certain user flows or pages in your app.