Drone v1 では Extension という仕組みが導入されました。
これは文字通り Drone を拡張する仕組みで、仕様に従って作れば自由に Drone を拡張できます。
https://docs.drone.io/extensions/overview/
全てを本体でやるのではなく、拡張する仕組みを提供し、あとはコミュニティに委ねるというのが Drone の一つの方針とも言えると思います。
Extension は非常に面白い仕組みだと思いますが、 Drone を運用する立場からすると中々頭が痛い仕組みな気がしてて、 自分は導入に対し慎重な立場です。 単なる杞憂で済めば良いのですが、その懸念について書きたいと思います。
根本は Drone Extension 固有の問題と言うより、一般的な拡張機構全般に言えることだと思います。 ただし、 Drone Extension は全てのビルドに影響を及ぼす、 CI/CDシステムが動かなくなるとサービスのリリースに影響を及ぼしかねないということからよりリスクの高いものになっています。
- 本体の drone/drone と比べ、開発は活発ではなく、サードパーティの extension はいつ開発が止まってもおかしくない
- 本体の drone/drone と比べ、ドキュメントやサポート体制が貧弱だと思われる(drone に関しては https://discourse.drone.io でサポートされているが、サードパーティの extension では難しい)
- ユーザーからの extension に関する要望を受け付けるようになると、管理者の負担になる
- extension のクォリティはマチマチであり、例外処理が甘かったり、ちゃんとエラーを吐かないものもあるだろう
- トラブルシューティングが難しいと思われる
- extension の仕組み上、extension を必要としないビルドにも影響を及ぼしうる
- 一度追加し、依存しだすと消すのが難しくなる
- extension が落ちると全 build に影響するので、耐障害性(冗長化)、モニタリングが必要
- etc
勿論、上記の懸念点は Extension によって提供される機能とトレードオフであり、 Extension の導入方針は Drone が運用される環境によって大きく依存すると思います。
例えば全員が顔見知りのような小さな組織で特定のサービス専用に Drone を使っていてかつ Drone の運用体制(人員)に十分余裕があるなら 積極的に Extension を導入しても問題ないかもしれません。
一方大きな組織で色々なサービスで同じ Drone を使っていてかつ Drone の運用体制が不十分(人手不足)ならば、 Extension の導入には慎重にならざるを得ないのではないかと思います。