EmotionTechテックブログ

株式会社エモーションテックのProduct Teamのメンバーが、日々の取り組みや技術的なことを発信していくブログです。

エモーションテックでの Renovate の活用

フロントエンド

こんにちはあるいはこんばんは。フロントエンドエンジニアの id:kasaharu です。

エモーションテックでは、今年の初めに Angular (+ NX) ベースのリポジトリに Renovate を導入し、半年以上継続して運用してきました。そこで今回は弊社の Renovate 活用について紹介します。

Renovate とは

Renovate は依存関係の更新を自動化するためのツールです。 詳細は 公式ドキュメント を参照していただければと思いますが、簡単に説明すると外部ライブラリバージョンアップのための Pull Request(以下、PR) を自動で作成してくれます。

開発をしていると、使っているすべてのライブラリのバージョンアップを逐一確認できず、気づいたときにはかなりの変更があり、バージョンアップに時間がかかってしまうという経験はないでしょうか？

そんな悩みの解消を手助けするツールが Renovate です。

Renovate の導入

すでにいろんな記事がありますが、まずは導入についてです。(なお、導入は 2023/01 上旬であるため情報が少し古い可能性があります)

弊社は GitHub を使ってソースコード管理をしているため、GitHub Apps 経由で導入しました。 GitHub Marketplace で公開されているので Renovate を探し、インストールします。 https://github.com/marketplace/renovate

インストールが完了すると Configure Renovate というタイトルの PR が作られるので、これをマージすることで設定が完了します。

どんな設定をしているか

公式のドキュメントを見ると、設定できるオプションだけでもたくさんあり、その数に圧倒されてしまいます。

https://docs.renovatebot.com/configuration-options/

弊社ではどのような設定を renovate.json に書いているか、その一部を紹介したいと思います。

プリセットの設定

まずはプリセットの設定についてです。今回は 2 つのプリセットを紹介します。

config:recommended

https://docs.renovatebot.com/presets-config/#configrecommended

公式が用意しているプリセットの一つで、広く推奨されている設定になっています。 以前は config:base というプリセットが用意されていましたが、その後継として現在は config:recommended があります。

今でも config:base を使うことはできますが、その中身は config:recommended に置き換わっているので、もしかしたらそのうち config:base は使えなくなるかもしれません。 https://github.com/renovatebot/renovate/blob/3c29bd4d7399fc2f89321376a9fcf570cabe0355/lib/config/presets/common.ts#L6

config:recommended には次のような設定が含まれています。

他にもいくつかの設定が含まれていますが、詳しくはドキュメントをご覧ください。

github>lacolaco/renovate-config:ng-update

https://github.com/lacolaco/renovate-config

こちらは Angular GDE の lacolaco さんが公開している共有プリセットになります。

弊社は Angular ベースのリポジトリであるため、こちらを使用しています。Angular はメジャーバージョンアップで破壊的変更が入る際に、CLI を経由したマイグレーションができます。もし、Renovate 経由でバージョンを上げてしまうとこのマイグレーションが実行されないままになり、アプリケーションが壊れてしまうため、それを防ぐために設定しています。

オプションの設定

次に個別に設定しているオプションについていくつか紹介します。

prConcurrentLimit

https://docs.renovatebot.com/configuration-options/#prconcurrentlimit

同時に存在できるブランチ / PR の数を制限するオプションです。デフォルト設定は 10 になっています。この設定を 0 に変更し、上限を撤廃しています。

一度に大量のライブラリの新バージョンが公開されたときに、この上限に引っかかると新しいバージョンが出たことに気づかないことがありました。

Renovate は prConcurrentLimit が制限されているときに priority に応じた順番で PR を作成します。priority を設定してない場合、デフォルトでは https://docs.renovatebot.com/configuration-options/#prpriority にある順番で PR が作成されます。ドキュメントを見るとメジャーがもっとも priority が低いことがわかります。 つまり、上限以上の更新がある場合、メジャーバージョンアップの PR がなかなか作成されず、気づいたときにはメジャーバージョンが 2 つ以上上がっている、なんてケースも発生してしまいます。

これを防ぐために上限を撤廃しています。

rebaseWhen

https://docs.renovatebot.com/configuration-options/#rebasewhen

Renovate が既存ブランチを rebase するタイミングを制御するオプションです。デフォルトでは次のどちらかの動きをします。

  • リポジトリが最新の状態を要求する場合は base branch から 1 コミット以上遅れると rebase する
  • 上記でない場合はコンフリクトしたときに rebase する

prConcurrentLimit の制限を撤廃しているため、rebase が多くなるほど CI を圧迫してしまいます。そのため rebaseWhen に never を設定することで、自動で rebase が走らないようにしています。

minimumReleaseAge

https://docs.renovatebot.com/configuration-options/#minimumreleaseage

stabilityDays と呼ばれていましたが、現在はオプション名が変わっています。対象のライブラリが公開されて minimumReleaseAge で指定した日数を経過していない場合に PR のマージを防ぐオプションです。

npm は、ライブラリの公開から 3 日以内であれば公開の取り消しが可能です。またアカウントの乗っ取りなどによって、汚染されたバージョンが公開されることもゼロではありません。

このようなバージョンをプロダクトに取り込まないように 3 days を設定しています。

configMigration

https://docs.renovatebot.com/configuration-options/#configmigration

Renovate の設定ファイルにもマイグレーションが必要なときがあります。ちょうど直前で紹介した stabilityDays → minimumReleaseAge の変更もマイグレーション対象です。 このオプションを有効にしていると、マイグレーションが必要になったときに Renovate が PR を作成します。

これらの設定ファイルは一度設定するとなかなか見直さない、なんてことも多いのでこのオプションを有効にしています。

lockFileMaintenance

https://docs.renovatebot.com/configuration-options/#lockfilemaintenance

lock ファイルをメンテナンスするための設定です。デフォルトでは無効化されていますが、これを有効にすることで package-lock.json を削除し、再作成します。 依存しているライブラリのバージョンが噛み合わなくなることもあるので、月に一回 PR を作成するように設定しています。

Renovate 設定ファイルの検証

Renovate には設定ファイルを検証するためのツールが用意されています。 https://docs.renovatebot.com/config-validation/

これを GitHub Actions で動かすことで、renovate.json に変更が入ったときの検証を自動化しています。設定ファイルは以下のように書いています。

name: Check Renovate Config

on:
  pull_request:
    paths:
      - 'renovate.json'

jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version-file: '.node-version'
          cache: npm
      - name: Validate Renovate config
        run: npx --package renovate -c 'renovate-config-validator'

どのように運用しているか

次は Renovate によって作られた PR をどのようにマージしているかを紹介します。

PR の影響範囲の確認

弊社では週 1 でフロントエンド相談会というフロントエンドエンジニアが集まる MTG があります。ここで、Renovate が作った PR を確認し、以下の振り分けをします。

  • リリース前の検証が必要となるアップデートであるか
    • すぐにマージができないため、チケット化してバックログに積みます
  • CI が通ればマージできるアップデートであるか
    • PR に専用のラベルを付与します。MTG 中はラベルの付与に留まります

人手による PR のマージ

専用のラベルを付けた PR を毎週マージしていきます。社内で Renovate の PR をマージする担当者を決めているので、担当者が持ち回りで作業します。

作業の手順は次のようなドキュメントにまとめており、誰でも作業できるようになっています。

auto merge の活用

Renovate には auto merge の設定があります。目視で影響範囲を確認しなくても CI が通っていればマージできるとわかっているライブラリは auto merge 設定を有効にしています。

しかし、対象のリポジトリでは 1 人以上の approve を必要とする設定をしています。このままでは auto merge を有効にしていてもマージされません。この問題を解消するため https://github.com/apps/renovate-approve を利用し、自動で approve する bot を導入することで auto merge を有効にしています。

導入時の注意として、renovate-approve はこれをインストールしたあとに作成された PR にしか適用されないという点があります。もし、インストール前にアップデートのあったライブラリにも適用させたい場合は、一度対象の PR をクローズし、再度ダッシュボード(Dependency Dashboard というタイトルの issue)から再作成することで、renovate-approve の対象になります。

まとめ

いかがでしたか？Renovate を導入しつつ、自動化できるところは人手を介さないことでローコストで安心できる開発環境を作れているように思えます。

顧客への価値提供はもちろんのこと、開発者が開発しやすい環境維持にも力を入れていきたいです。

エモーションテックでは顧客体験、従業員体験の改善をサポートし、世の中の体験を変えるプロダクトを開発しています。プロダクトに興味のある方、Angular を使ったアプリケーション開発をしたい方、ぜひ採用ページからご応募をお願いいたします。

hrmos.co