Upgrading GitHub to Rails 3 with Zero Downtime
shayfrendt.com
shayfrendt.com
For those of you keeping score:
- Yes, Rails 3 was released four years ago
- Yes, the current stable version is Rails 4.1, which left us
two major versions behind
We had work to do in order to live in the modern world again.
Let's say you need to set up a replicated database with failover and monitoring.
First you set up the database (and make sure it works).
Then you set up monitoring (and make sure it works, too).
Followed by replication (which should also work).
And finally, automatic failover (there's a pattern here...)
This sounds obvious, but I've worked with developers that, when given this task, tried to set up the entire thing in one shot. It took them over a month to wrap up, and they didn't have time to properly test it, because they bit off too much in one go.
The same goes for migrations. You work along an incremental plan to move from Point A to Point B, where at every step of the way, the set of things you need to change is small enough to manage, and you have the option of rolling back.
I can't imagine that Github has a tiny codebase, so I could totally believe six months for a zero-downtime Rails 2.x -> 3.0 migration. The next big step (3.0 -> 3.2) will be easier from what they learned in the first step, as will the step after that (my guess is 3.2 -> 4.0).
The U.S. Healthcare system has tried to switch to ICD10 standards for a while now, but they keep bumping back the deadline. I think it's EOY 2015 right now.
ICD10 was released in 1992...
Those two and a half years were spread over dozens of tools, a svn->git migration, two rewrites of the core functionality, but it all stayed on track because I was building small pieces which did limited things, and chained them together (the unix-y philosophy). I could build some functionality, test it, integrate it into the tool, and use it for a while. Then I could add support for it to our distributed RPC-ish system, and then if that worked, I could add it to our automated scripts.
If I had to build the whole thing at once I probably would have ended up with a much nicer, cleaner design, a much worse product, and a far longer deadline, and we wouldn't have had useful automation tools for the two intervening years.
3.0 deprecates a ton of stuff in 2.3. 3.2 actually removes it all and adds in the asset pipeline.
Best to not bite off more than you can chew.
(The fact that 2->3 was, like for most, also ruby 1.8 to 1.9 probably contributed)
2 -> 3 migration is VERY VERY hard. 3 -> 4 should be relatively easy in comparison.
ActiveRecord 3.x still supports the query interface used in 2.3, I'm guessing this is how they're able to run both versions from the same codebase.
I'm not sure which Ruby version GitHub is on, but Rails 4 requires Ruby 1.9+. Running Rails 2.3 on Ruby 1.9+ is doable but tricky.
If I had to guess, I'd say it's easier to hit Rails 3 as an intermediate milestone before moving onto Rails 4.
Ruby 1.8.x -> Ruby 1.9.x requires quite some work by itself.
Is Rails 3 worse performing than Rails 2? Would some performance loss be okay if they had a better codebase?
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.
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.
But I understand why they did it. And I sympathize. The Rails treadmill is a harsh regime.
I wonder if they're considering what the heck they are going to do when Rails 5 comes out (target: spring/summer of 2015. Less than 12 months) and Rails 3.x stops even receiving security updates. I mean, clearly they have the resources to backport security updates themselves that's not a problem -- it's just that they're still not quite in 'the modern world', they've just kept from falling even further behind.
While it says `/security`, it's actually the only link I know of with an updated list of how the maintenance policy applies to current versions.
I hadn't been able to find such before, only dated news/blog announcements, which can get out of date really quickly as fast as Rails goes.
map.resources :users
vs.
resources :users
We plan on gradually upgrading our routes file to use the new syntax now that we're on Rails 3, but as you can imagine it's something that we're going to need to be slow and careful about.
yep, I've upgraded a hundreds of thousands of Rails 2 codebase to Rails 3 point or so and it is a real pain. (Not to mention Ruby 1.8.7 to Ruby 1.9.3 conversion, oh boy!)
The good thing about the experience is that I have mastered upgrading Rails 2's codebases to Rails 3 or so and Ruby 1.8's codebases to Ruby 1.9's or so.
> We already have the app booting on 3.2; the goal is to try to get to 4.0 and track master fairly quickly. No one's eager to have to go through this whole process again in a year. ;)