hacomono TECH BLOG

フィットネスクラブ・スクールなど施設・店舗のための会員管理・予約・決済システム「hacomono」 開発チームの技術ブログ

「緊急で重要」なrenovate, dependabotの更新

こちらの記事はhacomono Advent Calendar 2023の17日目の記事です

はじめに

こんにちは、hacomonoでエンジニアをやっております野崎(社内ではサイモンと呼ばれています)です。

ここ数ヶ月で作業的に運用できるようになってきた、renovate/dependabotの運用を書いてみます。

renovate/dependabot

renovate / dependabot は、どちらもリポジトリのソースコードに含めている依存ライブラリ(パッケージ)を自動でスキャン、および更新PRを作成してくれるサービスです。

これらはどちらも、「自動でPRを作成してくれる」便利なサービスですがdependabotはライブラリの脆弱性監視に重心があるいっぽうでrenovateはライブラリの更新全般をサービスのスコープとしています。

本記事ではそれらをどのように運用しているのか、またその理由を書きます。具体的な導入や設定の方法は各サービスのドキュメントをご参考ください。

なお、renovate/dependabotは運営元の異なるサービスですが私のチームではまとめて取り扱っている(区別する理由があまりない)ので、以下断りがなければ区別せず取り扱っているものとします。

自動PRによる更新オペレーションの対象

本稿が対象とするrenovate/dependabotの対象リポジトリは、私がおもに関わっているプロジェクトです。

SaaSの本体とはアーキテクチャもリポジトリも別れているコードベースであるため、モノレポ・モノリスで運用する場合と比較すると難易度は低くなっています。

依存ライブラリも負債になる

具体的な運用にふれる前に、renovate/dependabot対応の重要性認識について触れておきたいと思います。

脆弱性への対処は常にやったほうが良いのはもちろんのこと、依存ライブラリの更新もできれば常にやっておきたい、と考えております。

重要なライブラリ(httpクライアントやjsonパーサ、その他便利ツール)を使っているとして、あるバージョンを境に破壊的な変更が加わってしまい、その後メンテナンスが困難になってしまうケースはよくあると思います。

最悪、メンテナンスされなくなり非推奨になってしまうことも…

メンテナンスが困難な状況になってしまうと、最新のバージョンを導入したり互換性のあるライブラリを検証したりといった作業が発生し、製品開発を止めなければならなかったり悪いときには放置するしかない状況に追い込まれる可能性もあります。

手遅れになる前に打てる対処をしておくのが、今の私のモチベーションになっています。

負債は常に返す

B/Sにおける負債のメタファーとは異なり、技術的な負債になりそうなものは常に更新しておくことで手がつけられない状態を防ぎたいですし、そういった意味でrenovate, dependabotの更新は負債になりうるものとして「やばくなったらまとめてみる」のを割けたいです。

リファクタリング同様、ライブラリの更新は「重要かつ緊急」な課題と(私個人は)位置づけています。

とはいえ、製品開発を見ているチームが、リファクタリングやライブラリアップデートに十分な注意や時間を払えないのも十分に承知しています。短期的に効果が見えないものなので、作業の価値が低く見られやすいですし、直接的に換金できる作業でもありません。

そのため依存ライブラリの更新は、ルールに則って運用的に更新できるのが望ましいと考えています。

renovate/dependabotの運用

設定を共有する

renovateは、更新タイミングや自動マージ可否など、非常に数多くの設定をいれることができます(導入できる設定は Configuration Options を参考)。

renovateの設定を簡素かつ共通にできるよう、設定自体はリポジトリに持たず中央集権的なリポジトリを用意してそれを各プロジェクトで読み込んでいます。

共通の設定を使う側のプロジェクトでは、 renovate.json を以下のように記述し、読み込む運用としています。

{
  $schema: 'https://docs.renovatebot.com/renovate-schema.json',
  extends: [
    'github>hacomono-lib/renovate-config:base',
    'github>hacomono-lib/renovate-config:npm',
    'github>hacomono-lib/renovate-config:npm-lockfile',
    'github>hacomono-lib/renovate-config:github-actions',
    'github>hacomono-lib/renovate-config:pre-commit'
  ]
}

更新の運用

先述のように、renovate/dependabotの作ったPRを定期的に確認・マージしていく運用をしています。

この運用を適用しているのはフロントエンドのプロジェクトなのですが、普段フロントエンドを触るメンバーで集まり、一つずつ見れる範囲で変更差分を確認しています。

CIではTypeScriptの型チェックやユニットテスト、ビルド実行など複数観点から見ているため、「CIが通ればそんなにまずいことにはならないはず」という前提に立っています(ある程度CIを信頼している)。

そのため、変更差分の確認自体はやるものの、CIが通れば比較的さくっとマージしています。

また、リリースの前後など「不用意に挙動が変わってほしくない」タイミングでは安全を取ってマージはせず、マージした後もQAプロセスに組み込みCIや目視で判断できる以外の観点からも動作を確認するようにしています。

マージしないこともある

CIをそれなりに信用しているため、CIが落ちるケースでは原則マージしないです(当たり前…)。わかりやすい例では、NuxtやVueなどフレームワークのマイナーバージョンがあがったタイミングで大きな変更が入ると、CIが落ちることがあります。

CIが落ちてしまう場合は、ソースコードの変更が必要なことも多いためリリースノートも読みながらアップデートに追従する作業も入れています。

なお、リリースノート読んでコード書き換えて…までいくと作業が結構膨れてしまうので、基盤チームも巻き込ませてもらい、作業が停滞しないよう推進しています(めちゃくちゃ感謝です)。

おわりに

私個人の拙い経験の中ではありますが、定期的に負債を返すようなオペレーションができていなかったり、やろうとしたときには手遅れになったことで結局大きな困難を抱えたことが何回かあります。

大きなリライト、リアーキテクチャは成功確度が高くないものですし、日頃からの取り組みが如実に出る領域と信じて、今後も継続的に続けていきたいです。


株式会社hacomonoでは一緒に働く仲間を募集しています!
採用情報や採用ウィッシュリストも是非ご覧ください!