上記のことが可能だったのは、施工管理サービスが全てコンテナで動作する2ようになっていた恩恵でした3。以下のおかげでこれを実現するのも比較的容易でした。引数として受け取ったRubyのバージョンでイメージをビルドするようにDockerfileが記述されていた。イメージのビルドを行っているCodeBuildも環境変数としてRubyのバージョンを受け取るように実装されていた。これを図にすると、以下のようになります。CIまた、動作検証期間中のCIは、以下のように設定していました。RSpecは本番環境のRubyバージョンである2.7とバージョンアップのターゲットである3.0とで並列実行させる。RuboCopは本番環境のRubyバージョンである2.7をターゲットとして動作させる。3.0用のGemfile.lockとで、特定のgem以外に差分がないことを確認する。2.7で動くコードが本番に適用される必要がありました。3.0へアップグレードすると動かなくなるコードをマージして欲しくありません。2.7と3.0とを並列実行させるようにしました。2.7と3.0とで並列実行させることも考えられました。2.7だけで動作させるように設定しました。2.7では違反にならず、3.0では違反になる記述を追加される可能性が低かったからです。3についてですが、Rubyバージョンアップの検証期間中も、その他gemのアップデートを通常通りに行いたいという要求がありました。3.0用に用意したGemfile.lockとに意図しない差分が発生しないよう、CIで監視しました4。プロジェクトの振り返りこのプロジェクトは特段の問題なく進行し、本番環境のRubyバージョンアップが完了しました。3.2がリリースされており、この勢いで最新バージョンまでアップグレードしたい意気込みです。今回のプロジェクトが問題なく終えられたのは、各チームの開発者の察しや機転によるところも大きかったと思います。今後は人に依存しない形でしっかりプロジェクトを進行させられるようノウハウを蓄積していきたい所存です。3.2へのバージョンアッププロジェクトに備えて、ここでは今回のプロジェクトの改善点を列挙しておきます。動作検証の期限とコードフリーズ日とには少し期間を空けておき、検証期限日に要修正箇所が発見されたとしても、その修正を反映するための余白期間を設けておく。動作確認依頼のリマインドがスルーされないように、@hereメンションでリマインドを送るのではなく、チーム単位で代表者を指名してリマインドを送るようにする。動作検証をしていただいている各チームへの依頼事項は課題発見のみで、発見された課題解決はRubyバージョンアップチームが担う旨を明確にしておく。オーナーが曖昧なAPIや非同期ジョブをリストアップしておき、今回のような広域の動作検証で抜け漏れが発生しないようにする。開発者の混乱を招かないよう、動作検証期間中は検証可能なデプロイ環境の提供方法を一貫しておく。まとめこの記事では、複数チームが開発を行うモノリシックなサービスのRubyバージョンを2.7から3.0へバージョンアップしたプロジェクトについて、プロジェクトの進め方とそこから学んだことについて説明しました。執筆時点(2023/02/14)での最新のRubyバージョンは3.2なので、このプロジェクトで得たノウハウを活かして、勢いそのまま最新バージョンまでアップグレードしたいと考えています。3.2からはYJITが実用段階になっているので、その際はパフォーマンス改善も絡めてご報告させていただければと思います^^最後にアンドパッドでは、様々な技術要素を活用して開発に取り組んでいます。一緒に開発、挑戦していただける方を大募集しておりますので、興味のある方は下記をご覧ください!engineer.andpad.co.jphrmos.co最近、チーム横断的な改善プロジェクトが立ち上がり、仕組みを改善しています。一部、開発者の作業用サーバがコンテナ化されていないので、絶賛改善中です。↩コンテナ化した経緯については、ANDPAD本体サービスをEKSに移行しましたや施工管理サービスの定期実行ジョブ処理基盤をEC2からコンテナへ移行しましたをご参照ください。↩r7kamuraさんが過去のテックブログで説明しているので、詳細はそちらをご参照ください。