Talks
Speakers
Events
Topics
Sign in
Home
Talks
Speakers
Events
Topics
Leaderboard
Use
Analytics
Sign in
Suggest modification to this talk
Title
Description
On August 15, 2018 GitHub accomplished a great feat: upgrading our application from Rails 3.2 to 5.2. While this upgrade took a difficult year and a half your upgrade doesn't need to be this hard. In this talk we'll look at ways in which our upgrade was uniquely hard, how we accomplished this monumental task, and what we're doing to prevent hard upgrades in the future. We'll take a deep dive into why we upgraded Rails and our plans for upstreaming features from the GitHub application into the Rails framework. By Eileen M. Uchitelle https://twitter.com/@eileencodes Eileen M. Uchitelle is an Senior Systems Engineer on the Platform Systems Team at GitHub and a member of the Rails Core team. She's an avid contributor to open source focusing on the Ruby on Rails framework and its dependencies. Eileen is passionate about security, performance, and making open source communities more sustainable and welcoming. https://rubyonice.com/speakers/eileen_uchitelle
Date
Summarized using AI?
If this talk's summary was generated by AI, please check this box. A "Summarized using AI" badge will be displayed in the summary tab to indicate that the summary was generated using AI.
Show "Summarized using AI" badge on summary page
Summary
Markdown supported
In her keynote address at Ruby on Ice 2019, Eileen Uchitelle, a Senior Systems Engineer at GitHub and member of the Rails Core team, discusses the intricate journey of upgrading GitHub's application from Rails 3.2 to 5.2. The talk emphasizes not only the challenges they faced but also the lessons learned that can guide other developers in similar situations. ### Key Points Discussed: - **Introduction to GitHub's Journey with Rails:** - GitHub has utilized Rails since its inception in 2008. - Initial rapid upgrades slowed as GitHub dealt with maintaining a fork of Rails. - **Historical Context of Rails Development:** - Rails was created from an actual application, Basecamp, to ensure practicality and effectiveness. - GitHub originally forked Rails due to performance issues that surfaced in Rails 3, complicating future upgrades. - **Technical Debt Accumulation:** - Over time, GitHub's customized fork diverged significantly from the upstream Rails repository, making upgrades increasingly difficult. - The lack of urgency to upgrade led to a build-up of technical debt that hindered GitHub's engineering effectiveness. - **Upgrade Process Description:** - After years of being impacted by their fork, GitHub's engineering team identified the need for a structured upgrade plan. - A dedicated team was assembled to facilitate the transition through an incremental upgrade approach, utilizing dual Rails versions during the process. - **Successfully Upgrading to Rails 5.2:** - After a myriad of challenges, including a substantial number of errors, the team completed the upgrade without downtime. - The process was marked by significant teamwork, tracking issues through GitHub project management tools, and refining the codebase. - **Conclusions and Future Aspirations:** - Uchitelle highlights the ongoing importance of regular upgrades, the value of staying current with Rails, and engaging with the Rails community. - GitHub's commitment to contributing back to the Rails framework was reinforced through this experience, leading to improved collaboration and innovation in the future. ### Main Takeaways: - **Importance of Upgrading:** Neglecting upgrades can lead to substantial technical debt, impairing performance and security. - **Trends in Application Development:** Adaptation is crucial for maintaining efficient and robust applications, as outdated frameworks hinder both productivity and talent acquisition. - **Collaborative Efforts:** Building a dedicated team for upgrades and utilizing community support can significantly enhance the upgrade process, promoting better practices and future-ready applications.
Suggest modifications
Cancel
