Ruby on Ice 2019: The Past, Present and Future of Rails at GitHub

On August 15, 2018 GitHub was deployed to production running Rails 5.2. This was a historic event; for years GitHub had been behind Rails and dependent on a custom fork of Rails 2.3. This talk will visit GitHub's past, including our tumultuous relationship with the Rails framework, and the grueling effort it took to get our application on the latest version. You’ll learn what mistakes to avoid and the reasons why such a difficult upgrade was worth it. We’ll explore what tracking master means for the future and establish that GitHub and Rails are in it together for the long haul.

Transcript

1. The Past, Present, & Future of at
2. Eileen M. Uchitelle ! " # @eileencodes eileencodes.com
3. ! I work at
4. a ♥
5. I’m on the Core team!
6. Upgrading at
7. The Past, Present, & Future of at
8. a ♥
10. Rails is born 2004
11. Frameworks are extracted, not built. -DHH “ ”
12. Rails 1.0 2005 2004 Rails is born
13. 2005 2006 2007 2004 Rails is born Rails 1.2 Rails 1.0
14. Let’s build a thing!
15. I’m in! Let’s build a thing!
16. 2005 2006 2007 2004 Rails is born Rails 1.2 GitHub is born Rails 1.0
18. 2005 2006 2007 2004 Rails is born GitHub is born GitHub launches 2008 Rails 1.2 Rails 1.0
19. 2005 2006 2007 2004 Rails is born 2008 GitHub is born Rails 1.2 GitHub launches Rails joins Rails 1.0
20. 2006 2007 2008 2005 2009 GitHub is born Rails 1.2 GitHub launches Rails joins Rails 2.3 Rails 1.0
21. GitHub is born GitHub launches Rails 1.2 Rails joins Rails 2.3 2007 2008 2009 2006 2010 Fork Rails
23. GitHub is born GitHub launches Rails 1.2 Rails joins Rails 2.3 2007 2008 2009 2006 2010 Fork Rails
24. fork repository
25. fork repository
26. GitHub is born GitHub launches Rails 1.2 Rails joins Rails 2.3 2007 2008 2009 2006 2010 Rails 3.0 Fork Rails
28. GitHub is born GitHub launches Rails 1.2 Rails joins Rails 2.3 2007 2008 2009 2010 Rails 3.0 Fork Rails 2011 Start 3.0 upgrade
29. GitHub launches Rails joins Rails 2.3 2008 2009 2010 Rails 3.0 Fork Rals 2011 Start 3.0 upgrade 2012 Rails 3.2
30. GitHub launches Rails joins Rails 2.3 2008 2009 2010 Rails 3.0 GH forks Rails 2011 Start 3.0 upgrade 2012 Rails 3.2 Upgrade stalled
31. Why upgrade when this version isn’t causing us pain?
32. Why upgrade when this version isn’t causing us pain? Why upgrade when Rails 3 is slower?
33. Why upgrade when this version isn’t causing us pain? Why upgrade when Rails 3 is slower? Why upgrade when our fork is better?
35. SECURITY BACKPORTS
36. SECURITY BACKPORTS HIRING IS HARDER
37. DEPENDENCIES ARE BRITTLE SECURITY BACKPORTS HIRING IS HARDER
38. DEPENDENCIES ARE BRITTLE SECURITY BACKPORTS HIRING IS HARDER DEVELOPMENT IS PAINFUL
39. 2010 Rails 3.0 2011 Start 3.0 upgrade 2013 Rails 3.2 Upgrade stalled 2012 Complete 3.0 2014 Rails 4.0
40. 2013 Rails 3.2 Upgrade stalled 2012 2014 2015 Complete 3.0 2016 4.0 started Rails 4.0
41. 2013 Rails 3.2 Upgrade stalled 2012 2014 2015 Complete 3.0 2016 4.0 started Rails 5.0 Rails 4.0
42. 2013 2014 2015 Complete 3.0 2016 2017 Eileen joins Rails 5.0 4.0
 started Rails 4.0
45. Gemfile.lock (Rails 3.2) $ rails server $ rails test tests/models/issue_test.rb Multiple Rails Versions Gemfile_rails4.lock (Rails 4.0) $ RAILS4=1 rails server $ RAILS4=1 rails test tests/models/issue_test.rb
46. Gemfile_rails4.lock (Rails 4.0) $ RAILS4=1 rails server $ RAILS4=1 rails test tests/models/issue_test.rb Multiple Rails Versions Gemfile_rails41.lock (Rails 4.1) $ RAILS41=1 rails server $ RAILS41=1 rails test tests/models/issue_test.rb
47. Conditional Code if GitHub.rails_3_2? # code for Rails 3.2 elsif GitHub.rails_4_0? # code for Rails 4.0 else # code for all future versions end
48. 2015 2016 2019 Rails 5.0 4.0
 started 2017 Eileen joins 2018 4.2 in prod
50. 2015 2016 2019 Rails 5.0 4.0
 started 2017 Eileen joins 2018 5.2 in prod 4.2 in prod
53. engineers at $ for hours = $ /hr
54. The cost of not upgrading is immeasurable
55. SECURITY BACKPORTS
56. SECURITY BACKPORTS HIRING IS HARDER
57. DEPENDENCIES ARE BRITTLE SECURITY BACKPORTS HIRING IS HARDER
58. DEPENDENCIES ARE BRITTLE SECURITY BACKPORTS HIRING IS HARDER DEVELOPMENT IS PAINFUL
59. DEPENDENCIES ARE BRITTLE SECURITY BACKPORTS HIRING IS HARDER DEVELOPMENT IS PAINFUL REWRITE IN MICROSERVICES
60. …the stories of upgrading being a huge undertaking always makes me scratch my head - what are we doing wrong if its easy for us. - HN troll “ ”
61. When upgrading you should…
62. When upgrading you should build a team.
63. When upgrading you should take time to make a plan.
64. When upgrading you should fix deprecation warnings early.
65. When upgrading you should add linters to prevent regressions.
66. When upgrading you should plan for the future.
68. You may regret forking Rails.
69. You may regret falling behind security supported versions.
70. You may regret using old, unsupported gems.
71. You may regret using private Rails APIs.
72. You may regret monkey patches.
76. This was my first major upgrade.
77. It’s important to remember…
78. It’s important to remember to pay debt down incrementally.
79. It’s important to remember you’re not alone.
80. It’s important to remember the payoff is worth it.
82. The benefits of upgrading
83. IMPROVED APIS
84. IMPROVED APIS SECURITY FEATURES
85. IMPROVED APIS BETTER PERFORMANCE SECURITY FEATURES
86. IMPROVED APIS BETTER PERFORMANCE NEW LIBRARIES SECURITY FEATURES
87. IMPROVED APIS BETTER PERFORMANCE NEW LIBRARIES SECURITY FEATURES A CHANCE TO CONTRIBUTE
88. The Future
90. 60+ Pull Requests from GitHub
91. Continuous Upgrades
92. Rails 6.0: Multiple database support
93. For the first time in GitHub’s history…
94. We’re pioneering the future of Rails.
95. We have a responsibility to support Rails
97. DEPENDENCIES ARE BRITTLE SECURITY BACKPORTS HIRING IS HARDER DEVELOPMENT IS PAINFUL
98. IMPROVED APIS BETTER PERFORMANCE NEW FEATURES SECURITY A CHANCE TO CONTRIBUTE
101. a ♥
102. Thank you! ! " # @eileencodes eileencodes.com