3 ms·

I went through the same upgrade process that the OP mentioned at scale. The company had 5 or 6 microservices that needed to be upgraded from Rails 3.1. While ha

I went through the same upgrade process that the OP mentioned at scale. The company had 5 or 6 microservices that needed to be upgraded from Rails 3.1. While having 10,000+ unit tests was very helpful for reducing regressions, we still had several huge problems: 1) We couldn't be sure that we hadn't broken something because we knew we didn't have 100% test coverage. 2) Some of the gems we depended on conflicted so severely that we had to rip them out and implement the solution ourselves or pick a different gem. 3) Our tests themselves of course contained code with breaking API changes. That means we had to maintain the tests as well as the production code through the upgrade, and had to make changes to many of those tests. All of this uncertainty means that this was not your typical test-driven confident refactor. QA still had to do massive regression testing, and we're pretty sure we introduced at least a new bug or two. It took a pair of devs 4 months of non-stop work to get these services up to Rails 4.1. The upgrade was absolutely necessary as the Rails core team had already stopped fixing major security holes in 3.1 long ago. The company incurred a tremendous cost during this upgrade process. If they would have kept things up to date all along they could've saved money, but of course that would have eaten into the supposed time-savings of Rails.

busterarm 10y ago
I believe it and know that sucked, but unfortunately in Rails 3 we got caught with our collective pants down in terms of security. Nobody competent was really auditing it (as was demonstrated against Github) to match the amount of momentum that it had. I see that as more of a Black Swan event than any inherent problem with the framework (yes, I'm basically blaming its users). This wasn't typical of the Rails 2 to 3 upgrade path and doesn't look like it'll be the 4 to 5 path either...and certainly not for incremental updates.
- engineerDave 10y ago
  I think your memory of the 2 -> 2.1 -> 2.2 -> 2.3 (if you were lucky to get bundler running) to 3 to almost immediate 3.1 with massive changes (asset pipeline) upgrade is a little fuzzy. It was the suck. A lot of companies I know of are still running Rails 2 because of this change.
  - borkborkbork 10y ago
    Which companies? _trollface_
borkborkbork 10y ago
This problem isn't specific to Rails 3.1. At some point, your frameworks need to be upgraded, because at some point the developers stop supporting your version. Django announced recently that 1.7 would no longer be getting security fixes. The question is: how much will it cost to upgrade when the day comes? Frameworks and communities that encourage less magic and less dependencies will always be less costly to maintain.
- engineerDave 10y ago
  true but even staying current across small SemVer changes can be a relatively large burden
  - borkborkbork 10y ago
    Agreed

busterarm 10y ago

I believe it and know that sucked, but unfortunately in Rails 3 we got caught with our collective pants down in terms of security. Nobody competent was really auditing it (as was demonstrated against Github) to match the amount of momentum that it had. I see that as more of a Black Swan event than any inherent problem with the framework (yes, I'm basically blaming its users). This wasn't typical of the Rails 2 to 3 upgrade path and doesn't look like it'll be the 4 to 5 path either...and certainly not for incremental updates.

engineerDave 10y ago
I think your memory of the 2 -> 2.1 -> 2.2 -> 2.3 (if you were lucky to get bundler running) to 3 to almost immediate 3.1 with massive changes (asset pipeline) upgrade is a little fuzzy. It was the suck. A lot of companies I know of are still running Rails 2 because of this change.
- borkborkbork 10y ago
  Which companies? _trollface_

borkborkbork 10y ago

This problem isn't specific to Rails 3.1. At some point, your frameworks need to be upgraded, because at some point the developers stop supporting your version. Django announced recently that 1.7 would no longer be getting security fixes. The question is: how much will it cost to upgrade when the day comes? Frameworks and communities that encourage less magic and less dependencies will always be less costly to maintain.

engineerDave 10y ago
true but even staying current across small SemVer changes can be a relatively large burden
- borkborkbork 10y ago
  Agreed