plugin アーキテクチャとは？ core を編集せずに拡張する

plugin アーキテクチャは、core を変更せずに、core が安定した拡張インターフェースに対してロードする別々のモジュールを通じて機能を追加できます。

plugin アーキテクチャは、小さく安定した core を保ち、任意またはサードパーティの機能を、定義されたインターフェースに準拠する plugin に押し出します。core はそれらを、しばしば runtime に発見してロードします。エディタ、CI システム、ブラウザが fork なしに拡張される方法であり、安定した plugin インターフェースは、実際の CI 上の意味を持つ契約になります。

core と拡張ポイント

core は拡張ポイント、すなわち plugin が実装するインターフェースや hook と、準拠する plugin を発見してロードする仕組みを定義します。core は特定の plugin について何も知らず、それらが満たすインターフェースだけを知っています。

なぜ役立つのか

core に触れたり fork したりせずに振る舞いを拡張する。
サードパーティが独立して plugin を作る。
無駄のない core を出荷し、必要な plugin だけを追加する。
plugin を独自の頻度で開発・リリースできる。

plugin インターフェースは契約である

拡張インターフェースは、core とすべての plugin の間の API contract です。不用意に変更すれば、制御できない plugin を壊します。したがって、公開 API に適用されるのと同じ backward-compatibility の規律がここにも適用されます。

matrix をテストする

core が plugin と動くこと、そして plugin が core のバージョン間で動くことをテストする必要があります。CI はしばしば互換性 matrix、主要な core バージョンと主要な plugin を実行し、どちらの側も単独のビルドでは見えない破損を捕捉します。

独立したリリースパイプライン

plugin は通常、core から切り離された独自の repository とパイプラインを持ちます。その独立性が利点ですが、core の変更が plugin エコシステムを静かに取り残さないよう、契約を両側からテストする必要があることも意味します。

スケーラブルな fleet での matrix 実行

core と plugin の互換性 matrix は、多数の並列ジョブです。スケールアウトするマネージド runner（Latchkey がそうであるように）は、それらの組み合わせを並行実行するため、matrix が妥当な時間で終わります。

重要なポイント

plugin アーキテクチャは、インターフェースを満たすモジュールを通じて安定した core を拡張する。
拡張インターフェースは、backward compatible であり続けなければならない契約である。
core と plugin の互換性 matrix をテストすることが、主な CI の負担である。