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


  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?