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.

Transcript

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% off!)
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?