サードパーティーのdependencyを最新に保ち、セキュリティーとメンテナビリティーを担保しよう

ラクマの亀井です。こちらの記事ではサードパーティーのdependencyを最新に保つことの重要性とどうやって最新に保っていくべきかを記載します。

サードパーティーdependencyはすぐに古くなる

ほとんどのソフトウェアはサードパーティーdependencyを使います。それは、必要な機能をすぐに使えるようにしたり、テストをもっとかんたんにかけるようにしたり、など様々な理由でしょう。そうやって開発を続けていくと、ソフトウェアが成長しコードベースも巨大になっていくと思います。しかしながら、ソフトウェアプロジェクトは、プロジェクトメンバーが十分な時間をとれないために、ときどきサードパーティーdependencyの更新を忘れることがあります。 

古いdependencyを使い続けるとどうなるか？

すぐに何かが起こる、ということはありません。しかし、古いdependencyがセキュリティー脆弱性を抱えていると、プロジェクトはセキュリティーホールを抱えることになります。そういった脆弱性はすぐに問題にならないかもしれません。そちらはソフトウェアのインフラ、運用フロー、ソフトウェアの使用方法に依存します。もし、ソフトウェアのインフラが外部からの攻撃に耐えうる強力なprotectionを備えているのであれば、脆弱性に関連したアラートが上がることはないでしょう。

では、dependencyの更新無しでプロジェクトを進めることが正当化されますでしょうか？私の考えでは、そうしたプロジェクトは開発体験の低下という問題に直面するのではと思います。おそらく、最近joinしたプロジェクトメンバーはなぜ、あるdependencyのAPIが使えないのか？ということを疑問に思うかもしれません。その理由はdependencyが古すぎるゆえに新しく追加されたメソッドを使えないから、というものになります。

古いサードパーティーdependencyはソフトウェア開発者に古いAPIを参照することを共用してしまいます。彼らはこの状況に満足するでしょうか？私の考えではNoです。 もしかしたら、彼らのうち数名は会社自体を辞めてしまうかもしれません。

Dependabotとは？

DependabotはGitHubの機能の一つで、dependencyをアップデートするためのプルリクエストを自動的に作ってくれるものです。Ruby、JavaScript、Pythonなど多くのプログラミング言語がサポートされています。加えて、セキュリティーアドバイザリーをモニターして、何かしらの脆弱性が存在すればすぐに対応してプルリクエストをオープンしてくれます。

DependabotはrepositoryにDependabotの設定ファイルを含めることで有効化できます。設定ファイルはシンプルなYAMLファイルです。これにより、Dependabotの挙動をコントロールできます。

なぜDependabotが便利なのでしょう？

dependencyのアップデートは容易に忘れるワークフローの一つです。それに、関連するchangelogやリリースノートへのリンクをプルリクエストのディスクリプションに載せる、という細々とした操作はかなり面倒です。そもそも、誰がアップデートを行いますか？アップデートを行う、というタスクを誰かにアサインする、といったことを「毎回」やっていますか？そうしたワークフローはすぐに問題に直面します。Dependabotはそうした問題を生まずに機能するという点で非常に有益だと思います。

どのようにしてDependabotを活用するべきか？

前提として CI/CD は必須

Dependabotによるdependencyのアップデートはプルリクエストに依存します。一度プルリクエストがオープンされると多くのrepositoryではCI/CDが走り、コードの変更がproduction環境にデプロイできるものかどうかをチェックします。CI/CDによるチェックがされることによってdependency単体のアップデートを自信をもって行うことができます。

言い方を変えると、CI/CDがない環境ではDependabotを使うべきではありません。なぜなら、dependencyのアップデートが既存のコードベースに取り込まれて機能するかどうかを確認できないためです。そうしたプロジェクトでは、まずはテストを書きましょう。

Dependabotがプルリクエストをオープンしたらすぐにデプロイする

もちろん、CI/CDによる新しいバージョンのdependencyの挙動のチェックは大事ですが、いくつかのアップデートはproduction環境でしか問題を発生し得ない可能性もあります。そこで、production環境にデプロイしてすぐに挙動を確認しましょう。もし、すぐにデプロイすることに躊躇するのであれば、staging環境を使ってみましょう。staging環境は多くの場合production環境と同等の環境です。こうした環境でアプリケーションが正常に動くことが確認できれば自信をもってdependencyのアップデートができるはずです。production/stagingいずれの環境であったとしても実際に動くアプリケーションで確認することが推奨されます。

一度にひとつのdependencyアップデートを

Dependabotを導入すると、最初はたくさんのプルリクエストがつくられて圧倒されるかもしれません。もしかしたらそうしたプルリクエストをひとつのブランチにまとめてstaging環境などに適用したい、という欲求にかられるかもしれません。もちろん、そうした方法でも問題ありません。その場合は、まとめたブランチをデフォルトブランチにマージすることを忘れないようにしましょう。

理想的には、一度にひとつのdependencyをアップデートしたほうがいいです。なぜなら、Dependabotが一度に複数のアップデートに現状対応していないからです。加えて、複数同時アップデートは複雑なワークフローを要求するかもしれません（複数のプルリクエストを一つのブランチにマージする、それをデプロイする、確認が終わったらブランチをデフォルトブランチにマージして関連するプルリクエストを閉じる、などのワークフローがかんたんに思い浮かびます）。もし、複数同時アップデートをstaging環境とあいのりするような状況だとdependencyのアップデートだけではなく他の変更も含まれていてなにか問題が起こったときに「何が原因か」特定するのに時間がかかる、などの問題が発生するかもしれません。 

どのようにしてDependabotのプルリクエストをレビューする?

Dependabotはプルリクエストをオープンするときに以下の情報を添えます。

• Release notes
• Changelog
• Commits

これらの情報はそのアップデートが適切なものかどうか判断するために重要なものです。多くのサードパーティーdependencyでは、どのような変更がそのバージョンに含まれているのかをリリースノートやchangelogを通して伝えています。そこには、新しい機能、バグフィックス、ドキュメントの更新、breaking change などが載っています。

まずは、こうした情報を注意深く読みましょう。もし新しい機能が含まれているなら自前で実装したutilityメソッドをそのライブラリーが提供する新しいものに置き換えることができるかもしれません。リファクターのチャンスですね。一方、breaking changes が含まれている場合コードベースの変更が必要になるかもしません。場合によっては"upgrading guide"のような情報を載せている場合もあります。こうした情報はdependencyのアップデートにおいてとても重要です。こうした情報を読み解いた後に「問題ない」と判断できたタイミングでアップデートのテストを行うといいでしょう。

しかし、そうしたアップデートするための必要な情報が欠けているがゆえにアップデートしていいものかどうか判断が付きかねるライブラリーがあるかもしれません。こうした場合は、そのライブラリーの commits を直接読む必要があるでしょう。しかし、リリースノートやchangelogが欠けているというのはそのサードパーティーdependencyのプロジェクトの体制に問題がある可能性があります。もちろん、commitsを読んで問題ないと判断できればいいのですが、多くの場合よくメンテされたプロジェクトほど十分なドキュメントを提供する傾向があるのは頭に入れておきましょう。

Dependabotのプルリクエストから学ぶ

Dependabotは非常に有益です。しかも、dependencyそのものから学ぶ機会も提供してくれます。いくつかのライブラリーはそれこそ魔法のような開発体験を提供し、開発者がそのライブラリーの細部まで知らなくても開発ができるようにしてくれます。Dependabotのプルリクエストはそうしたライブラリー自体について学ぶチャンスになります。どのような変更がされたのか？なぜその変更が必要なのか？を探って関連コードを読むうちに自ずとそのライブラリーのことがわかるようになってきます。また、ライブラリーのコードを読むことでその言語自体のエレガントな書き方などを学ぶことができるかもしれません。

加えて、所属するプロジェクトのドメイン知識を学ぶチャンスでもあります。dependencyのアップデートを適用する際には既存のドメインロジックを含んだコードの適用されうるかどうかを検討する必要があります。こうしたときに、アプリケーションのソースコードを読む必要がありますが、これによって、プロジェクト特有のコードに慣れるというメリットがあります。特にプロジェクトに join したばかりのメンバーにとっては有益な活動だと思います。

まとめ

Dependabotは多くのプロジェクトで有益です。CI/CDを有効活用することで、安全かつかんたんに dependency アップデートができるようになります。Dependabotのプルリクエストがオープンされたらリリースノートやchangelogを読んでそのアップデートが適用可能かどうかを吟味しましょう。こうした取り組みによって、ライブラリーそのものやプロジェクト特有のドメイン知識そのものの学習につながります。