Upgrade to Pro — share decks privately, control downloads, hide ads and more …

So Long, Hoboken: Migrating from Sinatra to Rails

So Long, Hoboken: Migrating from Sinatra to Rails

This is my RailsConf 2015 talk, "So Long, Hoboken: Migrating a Huge Production Codebase from Sinatra to Rails," delivered April 21st, 2015 in Atlanta, Georgia.


Eric Weinstein

April 21, 2015

More Decks by Eric Weinstein

Other Decks in Programming


  1. So Long, Hoboken Migrating a Huge Production Codebase from Sinatra

    to Rails # Eric Weinstein # RailsConf 2015 # April 21, 2015
  2. About Me ! @ericqweinstein ! ericqweinstein Promo code: RAILSCONF (40%

  3. Caveat Developer There are no silver bullets.

  4. Why Migrate? (Code) • Managing complexity • Tooling (gems, services

    like Code Climate) • Security, maintenance, DevOps • Application performance
  5. Why Migrate? (People) • Community involvement • Literature & developer

    education (blog posts, tutorials, demos) • Developer performance • Hiring!
  6. Okay. How?

  7. Our Architecture

  8. Option #1: Mounting • Pros: Continue to keep separate units

    of code separate; work of switching to Rails commands is done up front. • Cons: Performance (loading both Sinatra and Rails); early commitment (what if it doesn’t work?); nontrivial up-front cost.
  9. Option #2: Strangler Pattern • Pros: No dual-loading of Sinatra

    and Rails; defer commitment (maybe we stop at Sinatra++ or Padrino if that works); ease developers into Rails’ way of doing things. • Cons: Makes it easy for us to only do the first 80%; requires significant team discipline, since Rails’ opinions don’t take effect as quickly; prolongs period during which the codebase is a special snowflake (especially to new hires).
  10. Step 0: Tests, Tests, Tests • You cannot safely perform

    a migration of this kind without comprehensive test coverage • Unit tests (RSpec) • Integration tests (RSpec, Mocha) • Black box / smoke / user acceptance tests (Watir, switching to Capybara)
  11. A Word on Automation • It will save all your

    (chunky) bacons • Essential for continuous integration • Automate as much as you (safely) can
  12. Step 1: Models • In our case, wrappers for service

    calls (e.g. creating Accessory < Item and Dress < Item) • Incrementally add in useful gems that Rails depends on (ActiveModel, ActiveSupport)
  13. Step 2: Controllers • Tricky; Sinatra conflates routes & controllers

    • Map existing “routes” to Rails routes • Bridge Sinatra’s route-controllers to Rails controllers (see next slide)
  14. Controller Code Example class App < Sinatra::Base extend RailsIntegrationHelpers #

    /hello -> TestController#hello rails_route :get, '/hello', to: 'test#hello' # /hello/:name -> TestController#greeting, passing params[:name] rails_route :get, '/hello/:name', to: 'test#greeting' end # Credit: https://gist.github.com/johnholdun/bafbb4131f1812bb2ae8
  15. Step 3: Views • Mostly moving things around • Deceptively

    dangerous; typos or errors here are often only caught by smoke/UAT • Leveraging Rails helpers & shedding home- grown ones
  16. Step 4: All the (Not So) Small Things • Good

    examples (e.g. one Rakefile to lib/ tasks/, hooking up Code Climate security features) • This is ongoing, would love to say it happens organically but requires a lot of attention and not-so-glamorous work
  17. What We’re Learning • Conway’s Law is real you guys

    • Beware the second 80% • Strangler pattern FTW • Testing and refactoring > Rails for Rails’ sake • Further reading: http://blog.steveklabnik.com/ posts/2012-01-17-moving-from-sinatra-to-rails
  18. puts 'Thanks!' end

  19. Questions?