はじめに
Renovateなどの依存関係の自動更新ツールを導入している方は多いと思います。こういったツールを導入すると、リポジトリの依存関係をきれいに最新に保つことができます。
......というのが理想なのですが、実際にはそう簡単な話ではありません。 こういったツールを導入しても、自動的に作られるPull Requestが溜まっていってしまうばかりで、バージョンアップの対応が追いつかず追従し切れなくなり、やがて運用に乗らなくなってしまった、という事はよくあるのではないかと思います。弊社内でも実際に運用できなくなってしまった事例がありました。
そんな中で、エイチームライフデザインの中でRenovateの運用を工夫することで、うまく依存関係を更新できている事例を紹介します。
自動車事業の事例: 優先度を見える化し、対応するリポジトリを決める
目的
対象のリポジトリ数が多く、対応人員も少ないため、重要度から逆算してやるべきかを可視化し、無理なく運用できる仕組みを作りました。
背景
ナビクルなどの開発を担当する自動車事業では、そもそも全くライブラリアップデートの文化がなく、一度作った後は保守されない状態になっていました。 対象バージョンがどんどん古くなっていく現状があり、まずはライブラリアップデートが自然に行われるようにRenovateを導入しました。
ただ、導入後しばらくすると事業タスクによる工数が理由で、Renovateがうまく回らなくなり始めました。 原因を分析してみると、工数による問題もありましたが、以下2点も問題があると考えました。
- 全リポジトリが対象で、やれる人がやる方式で回していたこと
- やったかやってないかの進捗確認ができていなかったこと
上記の問題を解消するため、各ライブラリごとの優先度を決め、その優先度の可視化と、対象のリポジトリのアップデートが進んだか進んでいないかを可視化するためのライブラリダッシュボードを作成しました。
概要
まずリポジトリを一覧化しました。すると数十種類のリポジトリがあり、同タイミングでアップデートし続けることは難しい事がわかりました。 そのため、まずは事業優先度毎にリポジトリを分ける議論をチーム内でしました。 優先度を分ける基準として、下記のように定めました。
- A群: 積極的に開発が行われているもの
- B群: 現状維持のもの
- C群: 社内ツール
そして振り分けた中で、どれくらいの頻度で行えば問題なく回せるかを議論し、1ヶ月、3ヶ月、1年に1回のように振り分けました。
そうして、振り分けた結果をスプレッドシートに転記しました。
そして、定期的に確認し、着手完了したか判断できるように、各振り分けごとに完了チェックシートを作るようにしました。 この完了チェックシートは,メインのシートのA群, B群, C群の箇所を記載すれば、自動的に下記のチェックシートにも転記されるようになっています。
また、1週間に1回の定例MTGの中で、このダッシュボードを確認して問題ないかをチェックすることで、習慣として身に付くようにしました。
結果
ライブラリアップデートをするにも、どこから手をつけていいか、どのタイミングでやったら良いかをrenovateで解消しつつ 独自のダッシュボードを作ったことで、対象範囲を絞って、計画的に行えるようになりました。 結果、古かったリポジトリも、何度かこのサイクルを回したことで、最新のバージョンに追いつくリポジトリが出てきました。
未解決の課題
懸念点として、最初に付けた基準から変更が行われない場合があるということです。 あくまで最初に付けた基準はその日時点での優先度で、状況によっては重要度が下がったり、逆に上がったりもあります。 この優先度の議論が継続的に行われないことで、A群に新規リポジトリが増えて、またタスクが回らなくなってしまったり、新規リポジトリが増えてもアップデート対象に入らないといったことが起こり得ます。 人員の異動や退職等によって、このダッシュボードの目的や意図が薄まっていき、とりあえずやっているという形にもなり得るので、時間が経てば経つほどそのリスクも上がりそうです。 ダッシュボードを見るときの基準を言語化してみたり、見直しを定期的なものとして入れてみたり、何かしらの工夫は必要になってくるだろうなと思っています。
金融メディア事業の事例: リポジトリごとの主要なライブラリのバージョンを見える化する
目的
ナビナビキャッシングなどの開発を担当する金融メディア事業では、各GitLabリポジトリにRenovateを導入するに当たり、そのリポジトリ内で使用しているライブラリのバージョン確認を手軽に行える手段が求められました。
背景
金融メディア事業では隔週で保守デーを設け、その日に必要な保守対応とその担当のアサインを決めるMTGを行っています。このMTGではそれぞれの事業で扱っているプロジェクトのライブラリのバージョンが適切であるかの横串でのチェックなどを行っています。しかしながら、緊急度が高いセキュリティパッチが配信された場合、多数存在する事業やプロジェクトから対応が必要となるリポジトリを特定する作業が非常に手間という課題がありました。この問題を解決するため、「vermie（バーミエ）」というツールの開発プロジェクトが始まりました。この名前は「バージョン見える」→「バー見え」→「vermie」と派生した造語です。
概要
vermieの要件として、金融メディア事業だけでなく他のGitLabを使用しているプロジェクトでも簡単に導入でき、メンテナンスコストを抑えられるように可能な限りPureRubyでの実装が求められました。また、その中で使用されているライブラリの各バージョン、具体的には「Gem」や「npmパッケージ」、そしてDockerfileに記述されているイメージのバージョンが取得できるシステム、並びにテストの記述による動作保証も求められました。各ライブラリのバージョン取得は、Gemfile.lockやyarn.lockなどを解析して行い、特にGemのバージョン確認にはGitLabのRuby gems APIを、npmパッケージのバージョン確認にはyarnlock gemを、Dockerで使用しているImageのバージョンは自作の簡易パーサーをそれぞれ使用しました。取得した情報はHTMLで出力し、GitLabのスケジュールを使用して平日の毎朝9時にCI/CDパイプラインが走るように設定され、生成されたHTMLはGitLab Pages上でいつでも確認できるようにしました。
結果
このシステムにより、保守デーのMTGで各担当プロジェクトが使用しているライブラリのバージョンを確認する手間が大幅に簡素化されました。各リポジトリ内のyarn.lockやGemfile.lockを直接検索・確認しなくても、vermieが出力したバージョン一覧をGitLab Pagesで参照するだけで、必要な情報を得られるようになりました。
未解決の課題
現時点で、vermieはGitLabのAPIを使用してGemのバージョンを取得しているため、GitLabのプロジェクトでしか使用できない制約があります。そのため次のステップとして、Gemのバージョンが記載されているGemfile.lockファイルを解析する別の方法を考案し、GitLab以外のプロジェクトでもvermieを使用できるようにしたいなと考えています。
まとめ
エイチームライフデザインにおけるRenovateを運用する上での工夫を紹介しました。自動車事業の開発においては多数あるリポジトリの中から優先度を見える化して対応するものを決めることで、無理なく運用できるようにしました。また金融メディア事業の開発ではリポジトリ毎の主要なバージョンを見える化し、バージョンアップの対応が必要なものを簡単に確認できるようにしました。
それぞれの組織や開発の対象、段階によって課題は様々です。Renovateはただ入れるだけではなく、その状況に合った工夫で運用に乗せていくことが大切だと思います。
