はじめに
2022年、日本で有数の成長企業の人材マッチングサービス事業のプロジェクトで以下の要求が発令された。その内容はanonymousでも驚愕するほどのものである。
「レポジトリで使用しているソフトウェア最新化ミッションのための穏健なる提案」
〜サポート期限が切れそうor切れてるので速やかにバージョンを上げよ〜
と題したそのプロジェクトの内容は以下の通り
- Rubyをバージョンアップ 2.6 => 3.x
- Railsをバージョンアップ 6.0 => 7.x
- ubuntuをバージョンアップ １x.04 => 22.04
- 上記のバージョンアップを一度に実行する
これは実話である。
穴だらけの水道管
ソフトウェアのバージョンが低いとどうなるのか。
開発する上で我々が直面した問題を挙げていくと、
- バグ解決の際に検索にヒットする記事が少なく調査が難航する
- あらゆるところでバージョン不整合が起き、何がバグの原因か分かりづらい
- Rubyバージョンアップの際はubuntuのC言語コンパイラが原因でエラーを吐いていた
- サポートが切れていると質問しても返ってこない
- 新しい技術を導入しようとするたびに古い依存関係が原因で行き詰まる
まさに負の遺産と呼ぶべきもので、プロジェクトの見えない工数増加に確実に結びつくのである
以下ではどのようにこれに対処したのかを定性的に説明する。
バージョンアップを実行（強行）する際に役立てばと思う。
バージョンアップを一気にやるとどうなるのか？
もう少し具体的なフローを振り返る
バージョンアップ全体像
- ローカル開発環境でバージョンアップする
- 確認作業をする
- 検証環境にデプロイする
- 確認作業をする
基本的には上記を土台となる技術から順にやっていき、最後のバージョンアップまで到達したら本番デプロイを行う。以下で補足する
確認作業とは
確認作業とは具体的には以下を指す
エラーなく実行できるか
- Rspecが実行できるか
- Rails Serverが立ち上がるか
- Jobのworker（sidekiqなど）が動くか
- それぞれの実行時にdeprecation warnが発生していないか
- あれば適宜修正する
確認作業はローカル、検証環境で各々実行するのが理想である。これをまとめてしまうと、問題の切り分けができずにバグ修正に余計に時間がかかってしまう。
まとめてやりたいせっかちな人は、詰まった時以下がおすすめ
- 細かくCommitを刻んでそこに戻る
- 同僚に状況を説明し解決策がないか聞く
特に２は優秀な同僚がいないと成り立たないが、そこさえクリアできればかなり強力なソリューションとなるだろう。客観的な視点はバグ解決に必須だからである。
２がないとバージョンアップは乗り切れなかったと言って差し支えない。
土台となる技術とは
基本的には上記を土台となる技術から順に...
今回で言うと、土台から順に
ubuntu, Ruby, Railsとなる。
当たり前だが、この順番でバージョンを上げないと上げられない。このあと具体例で解説する
一気に上げるコツ（非推奨）
どうしても一気に上げたい人以外はここで画面を閉じよう
土台部分から上げる
プロジェクトの当初はRuby、Railsのみ上げる予定でubuntuはいつかやる予定だった。
ただ実際に作業を進めていくとubuntuパッケージ依存としか思えないバグを大量に捌く必要が出て来たのでフローを見直しubuntuを最新にしてからデプロイすることにした。
結局その英断で処理すべきバグはほとんどなくなり無事検証環境でデプロイできるようになった。
ここで大事なのは、仮説ベースのプロセスを見直し方針変更をチームメンバーに伝え相談することである。
Gemfile.lockを消す
具体的な話になってしまうが、Gemfile.lockを保ったままやるとかなり時間を食う。
QAを実施することを前提にGemfile.lockを消して全てGemを更新するのが良い。
スクラム開発ではやらない
そのプロジェクトは基本的にスクラム開発で進めていたが、バージョンアップ系はスクラム開発でやらない方が絶対にいい。絶対に。
- 細かくチケットを切るスクラム開発では、大量に出てくるバグを処理するのが面倒になる
- やることが多すぎるのでスプリント単位で工数を確保できないなら完遂できない
- スプリント単位に収まりきらないので、収まりきらないことに担当者がストレスを感じる
本プロジェクトでは、しっかりと工数を確保してくれる敏腕プロダクトマネージャがいたお陰で上記の問題を回避できた。エンジニア一人を専属でアップデート作業につけるという荒技もBiz側の理解があってこそ。
カバレッジが低くても完遂する
リポジトリによってはカバレッジが低いこともある。
ソフトウェアのバージョンの低さとカバレッジの低さは相関関係があるとはよく言われていることである。
だが、それでも諦めずにできるところから始めよう
システム全体ののQAテストを設計し、それを全て実行すればカバレッジの低さは問題になり得えないのだから！（適当）
参考
Discussion