多くのプロジェクトでは、生産性やコード品質、保守性の向上などの目的で、複数のパッケージを使用して開発を行っています。
これらのパッケージは、世界中の開発者によって日々更新されており、その内容は新機能の追加やバグ修正だけにとどまらず、脆弱性対策が含まれることもあります。
パッケージを常に最新の状態に保つことが理想的ですが、依存関係の問題などから、パッケージの更新は手間や時間がかかってしまうため、開発者自身が日々監視して更新する作業は現実的ではありません。
そこで、本記事では、私の参画しているプロジェクトで導入しているパッケージの自動更新を行うツールについてご紹介します。
※GitHubを用いて開発することを前提としています。
Renovateとは、パッケージの自動更新を行うオープンソースのツールです。
コード内で使用しているパッケージのバージョンを自動的に監視し、最新のバージョンが利用可能になるとpull requestを作成し、パッケージのバージョンを更新することができます。また、依存関係の更新に伴う脆弱性の修正や改善を通知することができます。
※脆弱性の通知に関しては、RenovateのvulnerabilityAlertsを有効にし、設定することによっても可能ですが、デフォルトでは無効になっているため別途設定が必要です。
多くのプログラミング言語やパッケージ管理システムに対応しており、npm や yarn、composer や pip だけでなく、Dockerfile や .node-version、.nvmrc なども管理できます。
DependabotとはGitHubが提供する、依存パッケージの脆弱性やバージョンアップを自動検知するツールです。
Dependabotには以下の機能があります
これらの機能は、GitHub.comのすべてのリポジトリで無料で使用することができます。
こちらもRenovateと同じように多くのプログラミング言語やパッケージ管理システムに広く対応しています。
お気づきの方もいらっしゃると思いますが、RenovateとDependabotには似た機能があります。
私のプロジェクトでは、
.node-version を使用)といった理由から、 Renovateを使用してパッケージを最新のバージョンに更新し、Dependabotを使用して脆弱性のあるパッケージを通知するようにしています。
またこれらを併用するか、片方を使うかに関しては、さまざまな意見や方法があります。
例えばMaterial UIやNestJSは、RenovateとDependabotを併用しているようですが、片方のみを使っている場合もかなり多くみられます。
私自身は、どちらが良いとか悪いとかはなく、目的や状況に応じて使用していくことが重要だと考えています。
RenovateもDependabotも、設定ファイルに記載することで設定をカスタマイズすることが可能です。
それぞれの設定項目や方法に関しては、Renovateはこちら、Dependabotはこちらに記載されていますので、確認してみてください。
設定の方針に関しては、
というように、基本的にはデフォルトに加え、必要なものを最低限設定するようにしています。
ツールの設定においてもYAGNI原則を適用するようなイメージです。
参考までに、私が参画しているプロジェクトにおいて、renovate.jsonは最低限以下のように記述しています。
{
"$schema": "https://docs.renovatebot.com/renovate-schema.json",
"extends": ["config:base"], // ※1
"timezone": "Asia/Tokyo",
"schedule": ["after 9:00 and before 10:00 every weekday"], // 始業開始のタイミングで確認できるようにする
"labels": ["renovate"],
"rebaseWhen": "never", // GitHub Actionsが自動作動するのを防ぐ ※2
"assignees": ["(自分のGitHubアカウント名)"], // PRを作成する度に自動でassigneeを指定する
"reviewers": ["(自分のGitHubアカウント名)"] // PRを作成する度に自動でreviewerを指定する
}
※1 デフォルトで設定されています。詳しい内容はドキュメントを確認してください。
※2 基本的にPR作成時にGitHub Actionsが動作するようにしており、かつ、ベースブランチが最新の状態でないとマージできないような設定をするようにしています。これは、プライベートリポジトリではGitHub Actionsは無料枠を超えると時間ごとの課金が始まるので、無駄なGitHub Actionsの動作を防ぐためです。
ただし、公式ドキュメントには
It is also recommended to avoid rebaseWhen=never as it can result in conflicted branches with outdated PR descriptions and/or status checks.
(古いPRの説明やステータスチェックが更新されず、競合したブランチが作成される可能性があるため、「rebaseWhen=never」を避けることも推奨されています。)
と記載あるので、状況に合わせて判断していただくことをお勧めします。
少なく感じるかもしれませんが、そのほか必要な設定は随時足していくというイメージです。
そもそも何が必要で不必要なのかが判断できない場合は、信頼性のあるパッケージやよく使うパッケージの設定を真似してみると良いと思います。
ここでいう信頼性のあるパッケージとは、メンテナンス状況、利用者数、GitHubリポジトリのスター数、コミュニティの活発さ、テストの有無といった多くの要素を伴うものを指しています。これらの要素はパッケージやツールの選定の際の指標にもなり得ます。
いざツールを入れても、実行に移すのが一番難しい気がします。
私が実際に行っている方法をご紹介するので、良かったら参考にしてみてください。
RenovateやDependabotの設定はしていても実践する人がいなかったら意味がありません。
プロジェクト内でレビュワーを決めて、Renovateに設定しておけば、他のpull requestと同様に忘れず対応できるようになると思います。
多くのパッケージはセマンティックバージョンに基づいています。
これはパッケージの互換性や品質を伝えるための規約であり、変更がどのバージョンにあたるかは開発者やメンテナーに委ねられます。 ただし、あくまで強制されるものではありません。
そのため、パッチバージョンであっても、リリースノートを確認し、変更差分を把握することを推奨します。
(リリースノートを読むことで、新機能や改良点、既知の問題点を把握することもできます。)
動作確認に関しては、メジャーアップデートの場合は、必ず動作に問題がないことを確認した上で導入し、マイナーアップデートやパッチアップデートの場合は、使用している機能に変更がある場合、手元で確認するようにしています。
(ただし、少しでも気になることがある場合は、バージョンに拘らず手元で試します。）
この際、自動テストが書かれていると、手動で実行する手間を省くことができるので尚良いと思います。
先程触れたように、バージョンの差分が大きい場合、確認が必要な箇所が増えます。
そこで、定期的に更新することによって、更新差分を少なくし、確認すべき箇所を減らすことができます。
したがって、日々の作業においても更新を怠らず、定期的に更新作業を行うことが重要です。
面倒くさがらずに、コツコツと更新作業に取り組んでいきましょう。
パッケージのアップデートは後回しになりがちですが、上手いこと習慣化していくと良いかもしれません。
設定や対応に関してはプロジェクトや環境に応じて最善の方法を模索していくことをお勧めします。