궤도升級至 6心得分享

分享最近把專案從 Rails 4.2升級到 6的心得.專案是公司內部用的系統.

TL;박사 01 명

Upgrading Ruby on Rails — Ruby on Rails Guides
細看 General Adivce 再根據要升級的版本去下面找對應的章節,即可升級

How to Upgrade Rails Without a Test Suite - FastRuby.io | Rails Upgrade Service
如果 테스트 덮어쓰기過低或者根本沒有寫自動化測試,可參考這篇文章的策略

왜?
其實呢,以一個內部系統而言,因為用的都是公司自己的員工,事實上似乎沒什麼特別去升級的必要.
不過公司有個「安全性」的考量,而許多 보석.存在安全性風險,而且在比較後面的版本都修復了,所以需要升級.但那些 보석.的版本被 궤도的版本卡住,以至於說需要將 궤도升級.
舊版本的 궤도也漸漸不再被維護,升級 궤도除安全性外也可以有更好的開發體驗吧!或者說,使用開源框架就是要跟著社群一起成長啊!
也避免公家機關那種:蛤你們還在用 windows 95?的這種情形
另個簡單的原因是:老闆就是要升級.這理由也夠充分了😅

專案介紹
我負責的專案是公司內部用的 고객 관계 관리系統,最早約 2013年就開始第一版開始使用了.
根據 지트的情形來看,主要開發人/團隊至少換過 5次甚至更多.
本公司是間純軟體公司,但「內部系統」不是正式賣給客戶的產品,狀態不佳可說是次等公民.

테스트 커버율差,也沒有引入 CI

後來都是外包,風格迥異

每個團隊都有自己愛用的 보석

過程
我們只有 2個開發者,2020年4月才入職.因為一開始就知道升級 궤도是目標之一,所以滿早開始就在想如何做到了.
我只有兩次升級的經驗,
第一次是台北某德商公司,궤도升到 궤도採用的策略是把 테스트 덮어쓰기幾乎補到100%.真的很屌...連 완벽한的測試都全補了.不過該公司在台北+德國有一堆工程師可以補測試.
第二次是幫某團隊從 궤도升到 궤도因為真的不是說多熟 궤도百花撩亂的設定,我那時是採偷吃步的方式...用搬的:我直接 새것了一個 난간的專案,然後,假如我要搬某個 모델我在新專案直接 rails g model 再把舊的程式碼一個個搬進去 이자의를 제거한다
多年以後,我還是對 궤도升級不熟이자의를 제거한다
但以上兩個方式都不適用了,我們只有2個人,뉴스 보도只有30%多,補完 테스트再升級可能老闆會凍未條;另外程式碼實在太多了,根本不可能用搬的,甚至有些 js引用的方式異常神祕,我連怎麼搬都不知道.
所以這次採用的流程如下,當然中間我們還是持續開發新的功能,所以就是每個禮拜安插一些時間來處理,前前後後大概花了셋個月吧~

引入 CI

修復既有 테스트

補上 테스트

移除不用的 보석

整理 특징.清單

升級

引入 단어
就是懶的在本地跑 rails 테스트 CI可是確保 지부 기구上的 테스트全過的檢查機制,沒過絕不要병합到主線裡啊!別讓情況變的更糟

修復既有 테스트
好像沒什麼需要補充的,不過花了非常多時間.

補上 테스트
雖然我們只有 2個人,在短時間內把測試補到超過 80% 幾乎有點不太可能,但還是須要做關鍵的 테스트那哪些算是關鍵的 테스트呢? 以我們的專案來說是:

모델的 유닛 테스트

서비스 대상的 테스트

對外開放的 미국 석유 학회的 테스트

移除不用的 보석.
每個團隊有自己愛用的 보석,舉例:有的人喜歡 타사:有的人喜歡 RestClient、有的人喜歡 파라다이스...做人要有雅量,但寫程式實在不用那麼大的雅量... 儘量把同樣功能的 보석.改用同一個,否則一個 보석.就是一個 DSL到時全部 보석.一起跟著 궤도大升級,又要重看每個 디지털 사용자 라인的使用說明,很耗時間.
移不掉或必須的 보석,如果擋到升級,會先 포크.到自己的 github修改再引用,之後再想看怎麼辦.
說是這樣說啦,其實應該還是打算移除,因為有些 보석.根本就掛了,連 수호자都跑了,你丟 공공 관계也不理你的이자의를 제거한다
其實這件事我到現在也尚未做完,所以才為什麼只升到 6而已 😅 而不是 6.1
但因為已經把安全性的更新都完成了~ 就先這樣

整理 특징.清單
因為整體 테스트 덮어쓰기最後其實還是不高,這樣子就要硬上風險太大了.幸好到 2021年時我們已經接獨這個系統 8個多月了,對於這個系統的功能,已大致了解完全.
大部分缺的是 컨트롤러或 시야.的 테스트, Rails裡的確要寫這兩種 테스트不是非常好寫...
不過,為了達到我們的需求,我改列了一個每個頁面上所有功能的清單,來做手動測試.
其實沒什麼祕訣,就是做一個非常長的 명세서를 대조하다依序檢查每頁的各項功能
我們記在 콘셉트上方便共同編輯,我剛快速滑了一下,大概滑了20秒才滑完,所以真的很長啊!
2人大概花了2天才完成這個清單.
而且完整地測一次大概要1天,所以測試很珍貴...
我們最後是測了 2次,最後一次是在上線前.
真的滿累的,真心覺得 컨트롤러, 보기的 자동 테스트不要省啊.
就算有 품질 보증也別累死 QA,讓 품질 보증去找更有價值的 가장자리 사례吧!
後來 루비 주간지上有分享這篇文章
How to Upgrade Rails Without a Test Suite - FastRuby.io | Rails Upgrade Service
主要核心也是列出完整的 특징.讓開發者或품질 보증在上 만들다前手動測試,看來邏輯還是正確囉

升級
前面都是在準備升級,現在才真的開始要升
升級時,直接切一個 지부 기구就開始做啦!
基本上是要參照前人的心得做: Upgrading Ruby on Rails — Ruby on Rails Guides
它的第一章 일반적인 건의非常重要,請務必詳讀
基本上 가이드 레일裡把跳下個版本會遇到的事情都寫出來了,就不再贅述.
分享一些特別的調整:

4.2 -> 5.0

컨트롤러 테스트的 params改為 키워드形式

Deprecated style: get “/new”, { id: 1 }, { “X-Extra-Header” => “123” }
New keyword style: get “/new”, params: { id: 1 }, headers: { “X-Extra-Header” => “123” }

환경 구성要明寫 적극적 사업的 대기열 어댑터
因為 4還沒有用到 ActiveJob我們都是直接 include Sidekiq::Worker5以後 행동 우체부直接繼承 재직 중

config.active_job.queue_adapter     = :sidekiq

5.0 -> 5.1

더러움的方法名稱變了

:changed 變成要選要 :will_change 或 :saved_changes

5.1 -> 5.2

變成 필수 사항,如果要保持空值需特別加註 필수 항목:false可以先關掉設定config.active_record.belongs_to_required_by_default = true

5.2 -> 6.0

자동 로드改成用 저트위크可以設定用原來的方式.config.autoloader = :classic

結果
4到 5真的多超多東西,5到 6變得就沒那麼多,但應該速度變快了
升到 6最有感的大概是 rails 서버啟動的速度吧...本來快1分鐘,現在大概10秒
再來是 기록기的格式清楚許多,知道產出 SQL是來自哪一行
也少了很多模棱兩可的寫法
更接近 현대적的 궤도開發體驗越來越好囉~ 讚啦~

如果能重來...我會

絕對先把要移除的 보석.來移除掉再升級,花非常多時間在處理 의존 관계

如果還是要持續使用某些不支援新版本 궤도的 보석,先 포크.一份,但確保能 병합回 상류否則對後來的同事來說,依然是一個沒人維護的 보석

補齊 테스트, Rails有了 view_component 的概念,我想 컨트롤러的 html回應應該比較好做 테스트補好 컨트롤러應該破 80% 的 테스트 덮어쓰기沒什麼問題,也可以避免更多問題了

最後上線後,唯一出問題的地方是 크랑조上面講的方法的確沒特別關心 크랑조...

大概就是這樣,倒不是什麼教學,祝大家升級圓滿