[心得]升級專案 PHP 版本
Upgrading GitHub from Rails 3.2 to 5.2
https://githubengineering.com/upgrading-github-from-rails-3-2-to-5-2/?utm_source=wanqu.co&utm_campaign=Wanqu+Daily&utm_medium=website
最近在公司進行某個專案的 PHP 升版 ，目標是從 7.1 升級到 7.2。
因為程式碼有點龐大，歷史又有點久了，升級的過程中意外的麻煩，
今天剛好看到這篇文章，值得借鏡。
本次升級的專案，因框架本身因為許多相容問題下個大版本中已解決但因為結構差異太大沒辦法生大版，只能想辦法去找出問題點，並嘗試去看一下官方的 issue 或 commit 資訊中尋找對應的解法，能升級小版本且不會與其他套件互沖的或是會互衝但可以解決的就升級，不行的話只能自己搬過來，個人覺得最困難的應該是找到真正的問題點在哪個環節，確認之後想辦法重現驗證，再去解決，底下是大致上的升級流程。
升級流程：
1.升級 PHP
2.跑測試，發現 PHPUnit 不相容
3.升級 PHPUnit
4.升級框架 PHPUnit 相關套件
5.成功跑測試碼，整理分類因升級導致的錯誤
6.比較 PHP 官方從 7.0 遷移到 7.1，7.1 遷移到 7.2 的所有內容，修正錯誤，以及檢查可能被影響但是沒出錯的程式碼(例如有些特性的移除或新增，或是即將棄用等，測試碼可能測不出來，或下個小版本可能會出問題，需要提前發現解決)
7.測試ＯＫ後，與維運人員合作部署到公司的開發環境
8.在開發環境反覆測試，不斷發現問題 ，修正問題
流程比較長的地方主要卡在三個部分：
1.有些程式碼屬於其他部門，要修正的話可能會影響到邏輯，需反覆溝通協調，
這邊雙方時程的掌握和追蹤因屬於不同部門，很難掌握。
2.由於區分開發，測試，正式環境，本身 branch 又是從正式環境長出來的，開發的時程拉長會不斷的遇到修好但是又出現有問題的 commit merge 上來，或是各環境本身某些邏輯行為就有差異，這部分只能整理一份注意事項給同事參考，降低寫出不相容的程式碼，以及勤勞到 code review 工具上注意所有正在開發中的 code，但最後不幸被 merge 有問題的 commit 的話還是只能自己修。
3.branch 跑在維運人員為了升級專案提供的測試 container 上，與實際的 container 可能因為部分參數的關係導致測試時行為皆正常，但實際部署上開發測試環境卻分別出現不同的問題，這部分屬於沒有考慮到實體機器與 container 上有所差異，以及各環境設定參數與資源多寡的問題。
這次就遇到測試時讀寫超過上限，發現可能是 LOG 機制出現問題，調整 PHP 與機器讀寫相關參數都無解，最後只能透過寫 shell 監控找出問題在重複開啟大量檔案，並找到橋接套件與套件本身的問題，進行修復。
另一個問題則是因為有一段對外呼叫測試碼沒有做 mock，在本機或單一 container 跑會機率性的成功或失敗，但在部署到開發環境的 container 中則必定失敗，推測是因為測試時 request 發到 localhost 但是開發環境測試 container 之間可能有互相蓋到，且因多人開發同時間不只單一個 container 再跑測試，因而被其他有 call 到 localhost 的測試碼影響。
結論：
1.溝通很重要
2.事前準備要做足，遇到問題邊查邊解決可能會漏了某些目前暫時沒出問題的部分
3.一些 devops 的知識需要加強，才有辦法與維運人員溝通，並釐清問題。
4.細心測試發現各環境差異，提出所有環境上適用的解決方法。（否則有可能Ａ通了，Ｂ卻掛掉）
5.評估所有解決方法，並以穩定以及變更最小為優先取捨方案 。（例如能透過調整小部分，達到避免全面性的調整，且維持原行為）
https://githubengineering.com/upgrading-github-from-rails-3-2-to-5-2/?utm_source=wanqu.co&utm_campaign=Wanqu+Daily&utm_medium=website
最近在公司進行某個專案的 PHP 升版 ，目標是從 7.1 升級到 7.2。
因為程式碼有點龐大，歷史又有點久了，升級的過程中意外的麻煩，
今天剛好看到這篇文章，值得借鏡。
本次升級的專案，因框架本身因為許多相容問題下個大版本中已解決但因為結構差異太大沒辦法生大版，只能想辦法去找出問題點，並嘗試去看一下官方的 issue 或 commit 資訊中尋找對應的解法，能升級小版本且不會與其他套件互沖的或是會互衝但可以解決的就升級，不行的話只能自己搬過來，個人覺得最困難的應該是找到真正的問題點在哪個環節，確認之後想辦法重現驗證，再去解決，底下是大致上的升級流程。
升級流程：
1.升級 PHP
2.跑測試，發現 PHPUnit 不相容
3.升級 PHPUnit
4.升級框架 PHPUnit 相關套件
5.成功跑測試碼，整理分類因升級導致的錯誤
6.比較 PHP 官方從 7.0 遷移到 7.1，7.1 遷移到 7.2 的所有內容，修正錯誤，以及檢查可能被影響但是沒出錯的程式碼(例如有些特性的移除或新增，或是即將棄用等，測試碼可能測不出來，或下個小版本可能會出問題，需要提前發現解決)
7.測試ＯＫ後，與維運人員合作部署到公司的開發環境
8.在開發環境反覆測試，不斷發現問題 ，修正問題
流程比較長的地方主要卡在三個部分：
1.有些程式碼屬於其他部門，要修正的話可能會影響到邏輯，需反覆溝通協調，
這邊雙方時程的掌握和追蹤因屬於不同部門，很難掌握。
2.由於區分開發，測試，正式環境，本身 branch 又是從正式環境長出來的，開發的時程拉長會不斷的遇到修好但是又出現有問題的 commit merge 上來，或是各環境本身某些邏輯行為就有差異，這部分只能整理一份注意事項給同事參考，降低寫出不相容的程式碼，以及勤勞到 code review 工具上注意所有正在開發中的 code，但最後不幸被 merge 有問題的 commit 的話還是只能自己修。
3.branch 跑在維運人員為了升級專案提供的測試 container 上，與實際的 container 可能因為部分參數的關係導致測試時行為皆正常，但實際部署上開發測試環境卻分別出現不同的問題，這部分屬於沒有考慮到實體機器與 container 上有所差異，以及各環境設定參數與資源多寡的問題。
這次就遇到測試時讀寫超過上限，發現可能是 LOG 機制出現問題，調整 PHP 與機器讀寫相關參數都無解，最後只能透過寫 shell 監控找出問題在重複開啟大量檔案，並找到橋接套件與套件本身的問題，進行修復。
另一個問題則是因為有一段對外呼叫測試碼沒有做 mock，在本機或單一 container 跑會機率性的成功或失敗，但在部署到開發環境的 container 中則必定失敗，推測是因為測試時 request 發到 localhost 但是開發環境測試 container 之間可能有互相蓋到，且因多人開發同時間不只單一個 container 再跑測試，因而被其他有 call 到 localhost 的測試碼影響。
結論：
1.溝通很重要
2.事前準備要做足，遇到問題邊查邊解決可能會漏了某些目前暫時沒出問題的部分
3.一些 devops 的知識需要加強，才有辦法與維運人員溝通，並釐清問題。
4.細心測試發現各環境差異，提出所有環境上適用的解決方法。（否則有可能Ａ通了，Ｂ卻掛掉）
5.評估所有解決方法，並以穩定以及變更最小為優先取捨方案 。（例如能透過調整小部分，達到避免全面性的調整，且維持原行為）
留言
張貼留言