3 ms·

If you know rails well and keep current, upgrading is perfectly straightforward, if uninspiring, work. It's a janitorial service of sorts, and it's totally app

If you know rails well and keep current, upgrading is perfectly straightforward, if uninspiring, work. It's a janitorial service of sorts, and it's totally appropriate for some corps to contract it out. It allows the developers with the best knowledge of the business to focus on that, where value is created. Regressions are mitigated by a strong culture of testing.

slimed 9y ago
I've spent many months upgrading legacy Rails services. One particular project was upgrading several microservices from Rails 3.1 to Rails 4. The projects made use of Rspec, Test::Unit, and Capybara. There were unit tests, integration tests, and UI tests. There were over 5000 specs in total. The project also used many gems in production to accomplish its tasks. When you are forced to uprgrade: the testing frameworks themselves, the ORM, the web framework, static asset building tools, libraries for managing file uploads, map rendering, etc, all in one go, it's nearly impossible to get it 100% right. We upgraded minor versions one by one. We read the Rails release notes and any gems that had them. Every time we bumped a Rails version we broke thousands of tests. Even after months of meticulous work we had only managed to upgrade 3 of the 4 services up to Rails 4.0, with another stuck on 3.2. Is it possible to work this way? Sure. But it's insane and costly when you let it get this bad. I've yet to work on a large Rails project on a team that outsources their upgrades where upgrading was "perfectly straight forward". It sounds like you work for a company that actually cleans house. A company like that has no need to hire OP.
- cutler 9y ago
  Just wondering how much of this upgrade pain is Rails-specific? How about Spring, Play and Django? What's so different about Rails?
  - slimed 9y ago
    I ran into such serious issues with Django and Django-CMS that we were unable to upgrade a Django 1.7 app to 1.8 without a ton of work and the possibility of data corruption. "Kitchen sink" frameworks like the ones mentioned above often lead to issues like this. I don't use Play framework any more when writing Scala. That being said, Rails truly was the pioneer for this type of web application programming. Many of the other frameworks are just copy cats.
    - cutler 9y ago
      Yes, I had a feeling Rails was getting singled-out unfairly. There's nothing about Rails which is more monolithic than, say, Spring, Django, Play or Laravel.
- desireco42 9y ago
  I actually went through that several times. It is not easy and requires specific expertise, like you said. Sometimes it makes sense to refactor parts. Microservices are not the only way to refactor. I like Trailblazer for example who for bigger codebases adds another layer of discipline.
deleted 9y ago
[deleted]
slimed 9y ago
Put another way: If you're always outsourcing work like upgrading Rails versions so that your devs can focus on "features" they will never learn which design decisions they are making are extremely costly in the long run. Like, hmm, maybe I shouldn't include 4 gems just to build and test my JavaScript. Or, hmm, maybe I shouldn't write this code in a way that leaks ORM details. Testing culture is great. But it is not an antidote for kicking-the-can-down-the-road culture.
- quesera 9y ago
  That I can agree with. I've been using rails since version 0.9, and my predisposition is to use as few gems as possible. Managed properly, rails and ecosystem churn is manageable. Managed poorly, it becomes reasonable to bring in an expert to repair your neglect. But it's definitely true that rails culture doesn't make itself easy to manage.

slimed 9y ago

I've spent many months upgrading legacy Rails services. One particular project was upgrading several microservices from Rails 3.1 to Rails 4. The projects made use of Rspec, Test::Unit, and Capybara. There were unit tests, integration tests, and UI tests. There were over 5000 specs in total. The project also used many gems in production to accomplish its tasks. When you are forced to uprgrade: the testing frameworks themselves, the ORM, the web framework, static asset building tools, libraries for managing file uploads, map rendering, etc, all in one go, it's nearly impossible to get it 100% right. We upgraded minor versions one by one. We read the Rails release notes and any gems that had them. Every time we bumped a Rails version we broke thousands of tests. Even after months of meticulous work we had only managed to upgrade 3 of the 4 services up to Rails 4.0, with another stuck on 3.2. Is it possible to work this way? Sure. But it's insane and costly when you let it get this bad. I've yet to work on a large Rails project on a team that outsources their upgrades where upgrading was "perfectly straight forward". It sounds like you work for a company that actually cleans house. A company like that has no need to hire OP.

cutler 9y ago
Just wondering how much of this upgrade pain is Rails-specific? How about Spring, Play and Django? What's so different about Rails?
- slimed 9y ago
  I ran into such serious issues with Django and Django-CMS that we were unable to upgrade a Django 1.7 app to 1.8 without a ton of work and the possibility of data corruption. "Kitchen sink" frameworks like the ones mentioned above often lead to issues like this. I don't use Play framework any more when writing Scala. That being said, Rails truly was the pioneer for this type of web application programming. Many of the other frameworks are just copy cats.
  - cutler 9y ago
    Yes, I had a feeling Rails was getting singled-out unfairly. There's nothing about Rails which is more monolithic than, say, Spring, Django, Play or Laravel.
desireco42 9y ago
I actually went through that several times. It is not easy and requires specific expertise, like you said. Sometimes it makes sense to refactor parts. Microservices are not the only way to refactor. I like Trailblazer for example who for bigger codebases adds another layer of discipline.

deleted 9y ago

[deleted]

slimed 9y ago

Put another way: If you're always outsourcing work like upgrading Rails versions so that your devs can focus on "features" they will never learn which design decisions they are making are extremely costly in the long run. Like, hmm, maybe I shouldn't include 4 gems just to build and test my JavaScript. Or, hmm, maybe I shouldn't write this code in a way that leaks ORM details. Testing culture is great. But it is not an antidote for kicking-the-can-down-the-road culture.

quesera 9y ago
That I can agree with. I've been using rails since version 0.9, and my predisposition is to use as few gems as possible. Managed properly, rails and ecosystem churn is manageable. Managed poorly, it becomes reasonable to bring in an expert to repair your neglect. But it's definitely true that rails culture doesn't make itself easy to manage.