HiTTOフロントエンドのRenovate運用
こんにちは、髪型を変えたらZIPのマーティンと呼ばれなくなったきょんしーです。
HiTTOではBackendとFrontendでリポジトリを分けており、それぞれでRenovateを導入しています。GitHub Apps - Renovate · GitHub として無料で使えるので導入が増えている印象です。
この記事では、FrontendリポジトリのRenovate運用をしてきての知見を共有できたらと思います。ベストプラクティスではないですが、所々参考になる箇所はあるかと思います。
運用開始前の状況
僕が入社した2021年5月時点でRenovateは導入されていましたが、PRが放置されている状態で運用に乗っているとは言い難い状況でした。
しばらくは機能追加やUI改善などに追われていたこともあり、ライブラリの対応に関しては後回しになっていました。React 17 に対応していないライブラリがあったりしたこともあり、Renovate対応に消極的になっていた部分もあったかと思います。
誰がレビューしても良いシステムになっていましたが、自由にしていいとなると逆に何をしたら良いのか分からなくなるのと同じような状況でした。誰も対応していない状況はまずいなと思ったのと、複業の方ともHiTTOの改善をしていきたい気持ちがあったので運用を見直そうと決意しました。
幸いなのかHiTTOではOKRを導入しており、四半期ごとに会社・部署・個人の単位でOKRを作成しています。そこで自身の個人KRに「複業の方も含めた開発の進め方やルールを定める」を定めてチーム開発をより良くしていくことにしました。
Issue, PRのテンプレートの改善やレビュールールの策定、複業の方にタスクをどのように取り掛かってもらうかなどを決めています。
Renovateの運用に関して
- Reviewerがアサインされてない
- PR作成の頻度やグルーピングなどが決まっていない
といった具体的な課題がありました。
※ 記事公開時点、HiTTOではフルタイムのフロントエンド担当者が2名、複業で関わってくださる方が2名います。複業の方は週8時間ほどを目安に仕事をしてもらっています。
チームでRenovateの運用を継続する
まずはReviewerを自動でアサインに関して取り掛かりました。 以下の記事にGithubでの設定とRenovate Configulationの設定に関して紹介しているので参考にしていただけたらと思います。
大まかなステップとしては以下になります。 1. reviewerにteamを設定すると自動的にチームメンバーがアサインされるように設定する 2. RenovateがPRを生成するときにreviewerにteamを追加するように設定ファイルを記述する
この設定だけだとライブラリのアップデートがあるたびにPRが作られてしまうので、運用に役立ちそうな設定などは積極的に取り込んでいます。 HiTTOのRenovateの設定の一部を抜粋・改変しています。
{ extends: ["config:base"], timezone: "Asia/Tokyo", labels: ["dependencies"], commitMessagePrefix: ":up:", branchPrefix: "renovate/", schedule: ["every weekend"], prConcurrentLimit: 15, prFooter: "Renovateの運用ルールのリンク", reviewers: ["team:frontend-all"], major: { stabilityDays: 7, prHeader: ":robot: IE11での動作確認もお願いします :robot:", }, minor: { stabilityDays: 3, prHeader: ":robot: 動作確認お願いします :robot:", }, patch: { stabilityDays: 1, }, vulnerabilityAlerts: { labels: ["security"], reviewers: ["team:frontend"], }, packageRules: [ // groupingとかしています ], }
prConcurrentLimit: Renovate が同時に作成するbranchとPRの数を制限するschedule: 基本は平日にソースコードの変更が多いので被らない土日にPRを作成するreviewers: HiTTOでは複業の方も含めたフロントエンド担当者のteamを作っていますprFooter: レビューで困った際に参照できるようにするために関連するドキュメントへのリンクを載せていますstabilityDays: 設定した日数が立たないとPRのステータスがSuccessにならないようにしています。majorアップデートなどの直後は何かしらバグを含むだろうという仮説の元にあります
ドキュメントを作成したりRenovateの設定を見直してから1ヶ月以上が経ちましたが、チームで運用ができてき出している状況を感じています。最初は今まで対応できていなかったpatch, minorのPRが沢山作られましたがほとんど対応でき、majorのPRが少しずつ作られるようにもなってきました。
まだまだ改善が必要
ただ、運用する中で改善点もいくつか見つかりました。
- 毎週末にPR作られるのは多い
- PRの数を制限しているとpatchアップデートのPRばかりになってくる
1つ目の課題に関しては、第1, 3土曜日にPRを作るようにしました。金曜に駆け込むような形でレビューすることがないように、毎日10時と18時にSlackで通知するようにしています。
schedule: ["on the 1st and 3rd day instance on saturday"]
2つ目の課題に関しては、prPriority を設定していないと minor, patch のアップデートのPRが優先的に作られるようです。そのため、majorアップデートのPRに届くことが少ないようにも感じていました。
解決策としては major, minor, patch それぞれに優先順位を持たせるようにしました。具体的には minor > major > patch の順になっています。
リリースの多さだけでいうと patch > minor > major の順になると思いますし、patchアップデートの重要性も感じているのですが、「1つのライブラリに対して毎週patchアップデートが来る」ことはレビューする側として面倒に感じてしまう側面もありました。major > minor > patch の順でも良いのですがmajorアップデートの対応ばかりになるのも疲れると思ったのでこのようにしています。
一旦はRenovate運用で抱えている課題を解消しましたが、今後も発生してくると思います。HiTTOはIE対応もしているのでアップデートをしないライブラリもどんどん増えてくると思うのでレビューだけ切り取っても大変ではあります。
最後に
1ヶ月ちょっとを通してRenovateの運用改善をしてる中で思ったのは、チームの状況や依存ライブラリの多さなどによって取るべき選択肢は変わるためベストプラクティスはなさそうということです。
もちろん、reviewerの自動アサインや定期的にSlackに通知したりすることは運用をしようとしている方々にとっては共通して必要なことだと思います。
この記事では触れませんでしたが、複業の方もいる中でのIssue, PRの作り方やレビュールール、タスクをどのように取り掛かってもらうか についても整理ができてきたら記事する予定ですので興味を持ってくだされば読者のボタンを押していただくかRSSリーダーに追加してもらえたらと思います。
HiTTOをもっとスピード感を持って改善し、チャットボットの良さをもっと広めていきたいのですがエンジニアがまだまだ足りないので募集しています！ 要求に従ってプロダクトを作るだけではなく、デュアルトラックアジャイルを開始し本当に価値があるのかを検証してから開発に取り掛かるようにもしています！Frontend, Backend, MLのエンジニアで興味がある方がいればHiTTOについて紹介する時間などをもらえたらと思いますのでTwitterからでも連絡くださればと思います！
