チームでの Renovate 運用を Code review assignment で自動アサインすることで持続させる!
Renovateをチームで運用できてますか?
問題なく運用できているかと言われたら「Yes!」と答えるのは難しい点もあるかと思います。
では、Renovateの対応は何が難しいのでしょうか?
- Dependencyが多いためPRも多くなり、処理しきれない
- 機能開発が優先になっていて手が回らない
- 関心がある人しか対応していない
- CIが通っていなく、修正のコストを考えるとアップデートしない方がいいという考えになる
など様々な要因が考えられます。
僕個人の主観ですが、関心がない人はRenovateをそもそも導入していない?にもかかわらず、チーム内で運用できていないのは機能開発が優先になっているという側面は大きそう...
Renovateを継続的にチームで運用していくために、この記事ではGithubの Code review assignment とRenovateの reviewers について解説します。手順に沿えば RenovateのPRのレビュワーを自動でチームメンバーに割り当てることができる ようになってます!
💻 Githubの設定
Code review assignmentの設定をしていきます。レビュワーにteamが指定されたとき、自動でチーム内のメンバーを割り当ててくれます。
Code review assignmentの設定方法
実際の流れに沿いながらCode review assignmentの設定を行なっていきます。
- まずはGithubの右上のプロフィール画像をクリックし、Your organizationsをクリックします。
- 続いてCode review assignmentを設定したいorganizationを選択します。
- チームの設定を行うためTeamsタブをクリックし、遷移先で対象のチームを選択します。
- ここまで完了したら本題のCode review assignmentの設定です。
- Enable auto assignmentにチェックして有効にし、teamをレビュワーに追加した時に何人にレビュワーを割り当てるかを設定します。
- レビュワーの割り当てに使用するアルゴリズムを選択します。
- Round robin: チーム内のメンバーを順番に割り当てます
- Load balance: 直近のレビュー合計数に基づいて担当を割り当てます
詳しくは以下を参考にしてください。
- Save changesボタンを押せば完了です!
レビュワーを自動で割り当てることができるようになりました!
📦 Renovateの設定
Githubの設定は完了しましたが、このままではRenovateが生成するPRに自動でレビュワーを割り当てることができないのでRenovateのConfigurationの設定をしていきます。
Configurationの設定方法
以下の最小限の設定から追加する形で説明します。
{
extends: ["config:base"],
timezone: "Asia/Tokyo"
}
とても簡単で、reviewers
プロパティを追加するだけです。
設定には team:
の接頭辞をつけてチームを追加する必要があります。
{
extends: ["config:base"],
timezone: "Asia/Tokyo",
+ reviewers: ["team:frontend"]
}
チームだけでなく、個人のアカウントを指定することも可能です。
個人のプロジェクトの場合は良いかと思いますが、チームで開発する場合は人数が増えたに都度修正する必要があるのであまりオススメはしません。
{
extends: ["config:base"],
timezone: "Asia/Tokyo",
+ reviewers: ["kyoncy", "foo-user", "bar-user"]
}
RenovateのPRを自動でチーム内のメンバーに割り当てることができるようになりました!
継続的に運用していくには文化も大事ではあると思いますが、少しでも役に立てばと思います!
RenovateのTips
さらに運用のことを考えていくと、Renovateの機能をフル活用する必要も出てくると思うので以下に自分が良いと思った設定を共有します!
{
extends: ["config:base"],
timezone: "Asia/Tokyo",
reviewers: ["team:frontend"],
// PRは週末に作成されるようにする(経験則ですが土曜の午前中は作り終わります)
schedule: ["every weekend"],
// Renovateが同時に作成するPRの数を制限する
prConcurrentLimit: 10,
// major, minor, patch によってCIを通過するまでの日数を設定する
// メジャーバージョン上がってすぐはバグが報告されるだろうという前提があったりします
major: {
stabilityDays: 7,
},
minor: {
stabilityDays: 3,
},
patch: {
stabilityDays: 2,
},
// minor, patch のPRを分けて生成する
separateMinorPatch: true,
// 個々のDependencyごとにルールを追加する
packageRules: [
{
groupName: "Reg Suit families",
matchPackagePatterns: ["^reg"],
// productionコードに影響がなければCIが通れば自動でマージされるようにする
automerge: true,
},
]
}
📖 参考記事
Discussion