<story><title>Upgrading GitHub to Rails 3 with Zero Downtime</title><url>http://shayfrendt.com/posts/upgrading-github-to-rails-3-with-zero-downtime/</url><text></text></story><parent_chain><item><author>ics</author><text>&lt;p&gt;&lt;pre&gt;&lt;code&gt;    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.
&lt;/code&gt;&lt;/pre&gt;
Okay, so why didn&amp;#x27;t aren&amp;#x27;t they transitioning to Rails 4? I&amp;#x27;m not clued in to much more than the version numbers so I suppose there are reasons that go a little deeper than &amp;#x27;the lowest version that works with the gems we want&amp;#x27;. They&amp;#x27;ve been working on the transition for six months according to the post, making it recent enough that 4 would be the &amp;#x27;obvious&amp;#x27; choice unless there were fears that it wouldn&amp;#x27;t be stable (IIRC Rails 4 has only been so for a few months).</text></item></parent_chain><comment><author>donw</author><text>An important lesson I learned while working as a sysadmin was that when you&amp;#x27;re making operational changes, you do one thing at a time.&lt;p&gt;Let&amp;#x27;s say you need to set up a replicated database with failover and monitoring.&lt;p&gt;First you set up the database (and make sure it works).&lt;p&gt;Then you set up monitoring (and make sure it works, too).&lt;p&gt;Followed by replication (which should also work).&lt;p&gt;And finally, automatic failover (there&amp;#x27;s a pattern here...)&lt;p&gt;This sounds obvious, but I&amp;#x27;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&amp;#x27;t have time to properly test it, because they bit off too much in one go.&lt;p&gt;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, &lt;i&gt;and&lt;/i&gt; you have the option of rolling back.&lt;p&gt;I can&amp;#x27;t imagine that Github has a tiny codebase, so I could totally believe six months for a zero-downtime Rails 2.x -&amp;gt; 3.0 migration. The next big step (3.0 -&amp;gt; 3.2) will be easier from what they learned in the first step, as will the step after that (my guess is 3.2 -&amp;gt; 4.0).</text></comment>
<story><title>Upgrading GitHub to Rails 3 with Zero Downtime</title><url>http://shayfrendt.com/posts/upgrading-github-to-rails-3-with-zero-downtime/</url><text></text></story><parent_chain><item><author>ics</author><text>&lt;p&gt;&lt;pre&gt;&lt;code&gt;    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.
&lt;/code&gt;&lt;/pre&gt;
Okay, so why didn&amp;#x27;t aren&amp;#x27;t they transitioning to Rails 4? I&amp;#x27;m not clued in to much more than the version numbers so I suppose there are reasons that go a little deeper than &amp;#x27;the lowest version that works with the gems we want&amp;#x27;. They&amp;#x27;ve been working on the transition for six months according to the post, making it recent enough that 4 would be the &amp;#x27;obvious&amp;#x27; choice unless there were fears that it wouldn&amp;#x27;t be stable (IIRC Rails 4 has only been so for a few months).</text></item></parent_chain><comment><author>jeremycw</author><text>2.3 to 3.0 is not that bad. 3.0 -&amp;gt; 3.2 is where the trouble will begin.&lt;p&gt;3.0 deprecates a ton of stuff in 2.3. 3.2 actually removes it all and adds in the asset pipeline.&lt;p&gt;Best to not bite off more than you can chew.</text></comment>