JIRAプラグイン開発方針のまとめ

業務上JIRAプラグイン開発をやっているので、その所感を開発方針という形でまとめてみました。

開発の課題と方針

Atlassianはプラグイン開発についてサポートしないし、公式のドキュメントも充実していない。おまけに、コミュニティも当てにならず、Stack Overflowでお目当てのソリューションを探すこともままならない。そのため、MarketPlaceに上がっているようなリッチなプラグインを開発しようと思えば、独自にフレームワークの解析を行う必要がありかなりの研究コストがかかってくる。おまけに、プラグイン開発で必須なコンポーネント及びモジュール群の機能についても知っておく必要があるので開発要員の学習コストもそれなりにかかる。

このように開発においてかなりの苦労が要求されますが、それでもなお自社の業務仕様に合わせてJIRAを拡張したいという需要はあります。そこで、プラグイン開発する新人向けに開発方針をまとめました。

方針1: リソース管理はREST APIを使う

JIRAのリソースと言ったらユーザ情報やプロジェクト・タスク情報。これらの管理はREST APIで十分です。主だったリソースはREST APIで取得・更新・削除できます。またJQL(JIRA Query Language)を利用すれば、条件に似合ったissue情報を好きなように取得することもできます。自社システムとの連携についてはこれで十分。あとマスタ管理であれば、JIRAのプラグインを作成するよりも別途システムを構築した方が製造及び拡張が容易です。

方針2: 主要なコンポーネント及びモジュールを押えておく

プラグイン開発のメリットは、JIRAのコンポーネントとモジュールを活用して自社の業務仕様に合わせJIRAの機能を拡張できる点です。中でも以下のコンポーネントとモジュールは使用頻度が高く、これらだけ覚えても有用なプラグインが作成できます。

ActiveObjects

独自のDBテーブルを生成します。他システムのマスタデータを取り込むときなどに使います。

EventListener

あらゆるイベントに対応する処理を付加します。

各種Manager系

IssueManagerやUserManagerなどリソース管理を行うコンポーネントです。リソース管理だけならREST APIで十分ですが、他のコンポーネントやモジュール上からリソース管理を行うなら必須です。

REST Plugin

独自のREST APIを生成します。JIRAの画面はフレームワークの制約が大きく、画面上のイベントからサーバ処理を行うにはREST APIを通じた非同期通信しかありません。そういう意味ではプラグイン開発必須のモジュールです。よくActiveObjectsとセットで利用されます。

各種Workflow系

JIRAの最大の利点といえば強力なWorkflowをおいて他にありません。WorkflowモジュールにはConditionとValidator及びPost Functionがあり、要望に応じて柔軟に拡張できます。

方針3: 画面作成は極力行わない

AtlassianにはAUIというフロントサイドフレームワークがあります。AUIにはAtlassianらしいデザインを作成するためのCSSと、Atlassianらしいモーションを実現ためのAJSが含まれます。AJSは単なるjQueryのラッパーではなく独自の関数やオブジェクトも含みます。使いこなせば有用なんですけど、ただでさえ学習コストの高いプラグイン開発のレベルを更に一段高くしてくれます。おまけに、フレームワークに従順するように開発する必要があるため、「あのページにコレ入れて」とか無闇に容認すると実現できずに失敗することになります。一見簡単そうに見えて複雑なのがフロントサイドです。

画面に対する要望は対応しないのがベストです。クライアントにはAtlassianの仕様についてよくよく理解してもらう必要があります（簡単そうなだけに）。それでも画面を作成するというなら、リスクを洗い出した上でその旨をクライアントを合意、後々もめないような手筈を整えておいてください。

最後に

開発できる仲間募集してます。