いきなりですが、あなたの会社では、プロダクトのコードはすべてゼロから書いていますか？よほど特殊な環境ではない限りほとんどのソフトウェアは面識も交流もない誰かが書いたコードを利用し、今日もどこかで新しいアップデートがリリースされています。
ソフトウェアの開発現場では依存しているパッケージ[1]のバージョンを最新に保っておきたいモチベーションがあります。なんとなくアップデートすることがよいと頭の中で思いつつも、 その言語化まで踏み込んだ経験はもしかしたら少ない のではないでしょうか？個人開発であれば導入の仕方を調べて単に設定を施してしまえば、あとは全部自動でアップデートをさせてしまうみたいなことも簡単です。しかし、チーム開発における導入の場合どうでしょうか？優先順位、工数、メンバーの合意等々、なんとなくよいという理由で片付けるには難しい問題に直面します。
そのような課題について私の体験を交えて、本エントリーでは以下の課題にフォーカスして執筆しました。
- パッケージバージョンのアップデートをチームの運用フローに乗せたい
- なんとなく Dependabot や Renovate で保守してたけど、「なぜ」を言語化をしたい
少しでも共感できる点があれば是非最後までお付き合いいただけると嬉しいです 😍
なぜパッケージのバージョンは最新に保っておきたいのか
Apple が毎年行っている iPhone の新機能発表で世間が賑わっていたのが、懐かしいですね。最近では少し落ち着いているようにも見えますが、 iPhone の新作発売日に徹夜する人で行列ができている様子がテレビで流れていたのはみなさんもご存知かと思います。新機能のリリースにはそれほどまでに強すぎる魅力があり、注目を浴びます。
最新を追従し続けることによって享受できるメリット
これはパッケージのアップデートも例外ではなく、バージョンが新しくなるにつれ、従来抱えていた問題が解消されたり、すぐにでも使いたくなるような新機能が追加されたりします。
新機能が早い段階で利用できる
このパッケージのここ、これができたらもっといいのになぁ…みたいなのが解消されることはよくあります。コミュニティーの運営方法によってもその特色は変わりますが、およそ需要の高い機能は優先的に実装される傾向にあります。そして、そのメリットを享受できるのは継続的に最新バージョンを適用し続けているプロダクトのみです。
漸進的に変更を受け入れ続けられる
とくにメジャーバージョンアップデートでは量の多少にかかわらず一般的に破壊的変更がつきものです。
ただでさえ新機能開発に追われているのに、緊急度の高いバグの根治にはメジャーバージョンアップデートが 2 回必要です(！？)
みたいなシチュエーション、最悪ですよね。日頃からアップデートする文化があればしていない場合と比べて比較的低コストで実行できます。
脆弱性が悪用される可能性が下がる
フレームワーク級の大規模なソフトウェアでは、セキュリティに対して専用の窓口が用意されていて、そこに報告された問題の修正は当然ながらバージョンアップデートによって対応されます。
https://github.com/vercel/next.js/security
開発生産性があがる
古い情報ほど、ネットでは更新されなくなりやがて姿を消してしまいます。このメソッド便利だと思って使おうとしたら次のバージョンからだった 🥹 みたいな経験ありますよね。
更新していれば調べる労力も代替案を検討する時間も省けます。
現実問題
さて、メリットをいくつか述べてきましたが、明日から導入しようとすると話が変わって少しむずかしくなってきます。
壊れる可能性がある
多くの場合パッケージから公開されている API のインターフェイスによって挙動が保証されている一方、パッケージ開発者の意図にかかわらず加えられた変更によって利用側の機能が壊れることもあります。
バージョンアップデートの度に手動で動作確認するのも1つの案ですが、その頻度と量によっては非現実的です。それに対する答えの 1 つが自動テストでしょう。どのようなテスト戦略であってもパッケージの挙動が変わった場合、気付ける可能性が大いにあるはずです。
逆に言えば、テスト戦略、CI の整備がしっかりと行われていることが前提となるため、今のプロジェクトに欠けている要素が可視化できたと捉えることもできます。
労力がかかる
変更を生じさせることには一定程度の工数がかかります。組織やプロジェクトによって種々の事情はあると思いますが、パッケージのバージョンアップデートから開発者を遠ざけている要因はメリットを享受する以前にやろうとするさいに直面する壁が多すぎることに由来しているかもしれません。
たとえば、テストに時間がかかる、アップデートの手動作業が必要、リリースに手動作業が介在、リリースブランチが長期間存在、上司から工数の承認が得られないなど、理由はいくらでも見つけることができそうです。
Renovate をチームに導入するさいの勘所
前節では、パッケージのバージョンを最新に保つことによって引き起こされるメリットとデメリットについて説明してきました。それを踏まえてチームに導入するための手段についてステップを追って説明します。
そもそも Renovate ってなんだっけ？
Renovate は、さまざまなパッケージマネージャーに対応したバージョンアップを支援・自動化するツールです。
Mend.io によって開発・運営されており、Mend Renovate Community 版では GitHub を始めたとしたさまざまな VCS へ統合されたものが無料で利用できます。
導入する目的を明確にする
あらためて導入する目的はなんでしょうか？私のチームでは、 Dependabot が導入されていたものの運用フローが属人化しており多くのアップデート PR が放置されている状態になっていました。 あなたのチームのどんな課題を解決するため なのか、課題を言語化し #なぜパッケージのバージョンは最新に保っておきたいのか で説明したメリットと併せて説明するとよいでしょう。
カナリーのマーケットプレイスチームでは、技術的な意思決定を ADR で管理しています。
チームで行ったパッケージのバージョンアップデートのフロー化と Dependabot から Renovate への移行も例に漏れずその土台の上で行われました。
Renovate へ移行する際に作成した ADR
今回の Renovate への移行では、フロントエンドのパッケージにありがちな モノレポのアップデートを 1 PR にまとめてくれる機能 であったり、 issue に作成される Dependency dashboard によるアップデートの見える化であったり、運用を効率化するための仕組みが整っていることが採用の決め手になりました。
どこまでラクするか決める
全自動は手間を削る意味では魅力的ですが、バージョンアップデートによって機能が壊れ、事業に影響が出たら本末転倒です。 壊れる可能性がある で以下の観点でいったん棚卸しをして、合意を取りながら進めるとスムーズにできました。
- 自動でアップデートしたいパッケージの一覧
- 各パッケージについて SemVer (major, minor, patch) 粒度での取り扱い
- 対象となる自動テスト (CI)
たとえば、 devDependencies ならば本番への影響はほとんどありえないのでテストが通れば patch は自動でマージしてもいいよね、という感じで議論が進められます。もちろん、これらは安全性と効率のトレードオフになるのでチームにとってもっともよいバランスで選択することがベストです。
マーケットプレイスチームでは、自動で作成された PR にはレビュアーが自動的にアサインされ週次のミーティングで対応漏れがないか確認することで運用しています。
非常にシンプルなスクリプトですが、これによって放置されてしまうアップデートがなくなりチーム全員でパッケージのバージョンアップデートに取り組むことができるようになりました ✨
おわりに
Renovate は非常に機能が豊富です。一方その中からチームにとって最適な機能を取捨選択することにより想像できるおおよその運用方法は達成可能です。定常業務を可能な限り自動化し、プロダクトの発展をより加速させていけると全員ハッピーですよね 😍
それでは、よい Renovate ライフを ✅
-
依存関係にあるソフトウェアのことを便宜上パッケージと呼ぶことにします ↩︎
Discussion