Github 升級到 Rails 5.2.1 了

摘要： 簡評：之前用的可是 3.2，早就該升級了啊。 Github 的 Rails 升級花了大約一年半的時間，這是有原因的，首先，Rails 本身的升級並不總是平滑的，有些版本有重大改變（breaking changes）。 Rails 改進了版本 5 的升級過程，這意味著...

簡評：之前用的可是 3.2，早就該升級了啊。

Github 的 Rails 升級花了大約一年半的時間，這是有原因的，首先，Rails 本身的升級並不總是平滑的，有些版本有重大改變（breaking changes）。 Rails 改進了版本 5 的升級過程，這意味著雖然 3.2 到 4.2 需要 1 年，4.2 到 5.2 只需要 5 個月。

另一個原因是 GitHub 的程式碼庫起碼有 10 年的歷史，多年來，技術債務逐漸增加，並且必然存在潛在的問題，如果使用的是舊版本的 Rails，工程師將不得不新增更多的猴子補丁（monkey-patch）或實現上游已經實現的功能。

最後，當我們開始時，並不清楚需要哪些資源來支援升級，因為我們大多數人之前從未進行過Rails 的升級，所以我們一直在學習。該專案最初由 1 名全職工程師和一小批志願者組成，我們將該團隊培養成 4 名全職工程師和志願者。每個版本的升級都意味著我們會學到更多，下一個版本的升級速度會更快。

通過這項工作，我們學到了一些重要的經驗，我們希望下一次升級更容易：

• 早升級，經常升級（ Upgrade early and upgrade often ）
• 保持升級基礎架構（ Keep upgrade infrastructure in place ）
• 使用上游提供的工具，而不是自己造輪子（ Upstream your tooling instead of rolling your own. ）
• 避免使用私有 api（ Avoid using private API’s in your frameworks ）
• 解決技術債（ Address technical debt often ）
• 增量升級（ Do incremental upgrades ）
• Keep up the momentum.
• Expect things to break.