Upgrading legacy rails

[keegan myers]

I recently started with APS and noticed that many of the gems we are working with are, or soon will be out of date. Our rails version is 3.2.x our ruby version is 1.9.3 . While this may not be am immediate red flag I would like to reach a point where each of our gems is within 2-3 sub versions of the most recent stable build. This way we should be able to avoid the constant dependency and deprecation issues we currently face. This leads me to several questions:

Is it reasonable and time/cost effective to keep everything  (ruby versions and gems) within 2-3 sub version of the current stable release? 

If so can someone propose a methodical way to bring our current application up to date? Keep in mind that we are tasked with "keeping the lights on" as well so we can not devote all of our time toward this project.

If this is not a reasonable goal then how current should we keep our application in order to minimize potential deprecation issues (relying on unsupported functionality). I don't need the latest and greatest functionality for the sake of it, though bringing SSE (http://robots.thoughtbot.com/chat-example-app-using-server-sent-events)  into the application would be nice. I just don't want to risk being so far out of date with our implementation that it becomes impossible to support in a time/ cost effective manner.

[Mark McEahern]

In an ideal world, this would be true:

1.  No version constraints in Gemfile

2.  Current versions only in Gemfile.lock, which is under version control

3.  No one ever naively does `bundle update` and checks in the result

4.  The system has 100% coverage with a blend of high-level acceptance tests, integration tests, and unit / functional tests

Then, routinely (say, probably no more often than weekly, not less often than monthly):

1.  Branch off master (or whatever production is)

2.  bundle update

3.  rake

Only if still green, investigate the Gemfile.lock diffs and for each update, verify via CHANGELOG of relevant gems, that there are no hidden gotchas in the relevant version changes.

// m

--
You received this message because you are subscribed to the MadRailers Google Group group.
To visit the MadRailers home page, go to http://madrailers.org
To post to this group, send email to mad-r...@googlegroups.com
---
You received this message because you are subscribed to the Google Groups "MadRailers: Madison's Ruby/Rails User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mad-railers...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Chris Arndt]

Hi Keegan,

I've had the same questions but unasked. The environment in where I work does not offer time to keep things updated to the current stable release unless a security vulnerability affects the applications.

Thanks for asking your question, am interested in the answers as well. The Rails apps I support are also using Ruby 1.9.3 & Rails 3.2.*

Chris

On Sun, May 11, 2014 at 7:06 AM, keegan myers <keeganm...@gmail.com> wrote:

--

[Jim Remsik]

Keeping things up-to-date for being up-to-date's sake isn't of particularly high value. It's a vitamin. Updating to remove security exploits is a must. As in most things in life there is not a black & white answer to when to update.

With limited resources it's you, or your team, should be aware of what is necessary and what is nice to have.

The best way I've found to manage this is a service called Gemnasium. $15/mo is way less than paying someone to keep abreast on all the new information available about every gem in your Gemfile let alone all of the dependencies hidden within.

Jim Remsik

j...@adorable.io

* Yes, we're hiring.

[Matthew Margolis]

Keeping up to date with every point release is often point-less (ba-dum ching), but if you fall behind on major releases of your core dependencies then you need to discuss the future development implications with your employer.

I have been part of a few development initiatives that resulted in applications that were locked to old versions of Ruby or Rails because time was not taken to keep semi-current and now it's incredibly cost prohibitive to upgrade those applications.  When a new security issue crops up there may be no patch for unsupported old versions, and your team may have to spend an unpredictable amount of time learning about the exploit and hand-rolling your own fix.  This is risky business.

I would suggest drafting up a dependency upgrade schedule with the stakeholders for your project.  You should make it clear which dependencies are core to the project and how often you think you will need to set aside time to keep them reasonably updated.  For example, you might want to declare a goal to be no more than 4 months behind the latest release of Ruby or Rails.  There will be times when you choose to wait longer, perhaps while a different dependency catches up to breaking changes, but in general you will plan to set aside a few days within 4 months of a major Ruby release. This kind of blank check pre-authorization is scary for clients/management, so it might help to make it clear that you will go through normal work planning channels if an upgrade turns out to be non-trivial. 

To be clear, I am not saying you should do this for all your gems, just the major dependencies.  I find that most of my non-core gems track my major dependencies anyway, so keeping Rails up to date keeps most other pieces from falling too far behind.  I do recommend running "bundle outdated" every few weeks and tackling the easy upgrades for small gems that won't have ripple effects in your codebase.


As far as how to put together a schedule:

1.  List out your main dependencies:  Ruby, Rails, Ubuntu, SASS, Foundation, AngularJS etc... 
2.  For each dependency indicate your target upgrade schedule and if you will need any other groups  to help with the upgrade.

3.  Pick a cadence to sit down with your employer and review how well the schedule is working for both of you.  Adapt as needed.

To prepare for this discussion I would recommend that you share the benefits of staying semi-current with your employer.  It's more difficult to say no when the upgrades are tied to value generation for the business.
-  You can use modern open source tools that requires new-ish versions of your dependencies.  Imagine being on Rails 3 and needing a plugin that only works on 4.  Not having to build your own adapter for TOOL_X can have a big impact on development costs.
-  Security fixes.

- Performance improvements in new versions of your tools.

- It's easier to hire new people who know current APIs than find candidates who know Rails 1/2/3.
etc..

- Matt Margolis