コンセプト
Automation for Jira Server によって、スクリプト不要で Jira を拡張して自動化できるようになります。レゴのようなものだとお考えください。ビルディング ブロックを組み合わせるだけで、必要なプロセスを簡単に自動化できます。
Automation for Jira Server をインストールするとサンプル ルールがセットアップされて、そこから作業を開始できます。
ルール
ルールとは Jira を自動化して拡張する方法です。各ルールは、ルールを開始するトリガー、ルールを絞り込む条件、それを実行するアクションで構成されます。ドラッグ & ドロップ インターフェイスによって、これらの構成要素を無限の方法で組み合わせて自動化ルールを作成します。
単純なルールの例は、Jira 課題が作成されて (トリガー) 優先度が「高」(条件) の場合は、課題をボブに割り当てる (アクション) というものです。ボブ、ごめんね!
これらの構成要素を組み合わせてカスタマイズすることで、ほぼすべてのユース ケースを解決できます。
トリガー
すべてのルールはトリガーで開始されます。課題の移行、スケジュールされたトリガー、課題の作成といった、20 個を超えるトリガーから選択できます。使用するトリガーを選択すると、左側の「トランク」に表示されるようになります。必要であれば、次のコンポーネントに移動してルールの完了前にトリガーをカスタマイズできます。
条件
条件によってルールのスコープを絞り込めます (例: 優先度が高い場合のみ、課題をエスカレーションする)。ルールに条件は必須ではありませんが、条件を含める場合はルール チェーンのどこにでも配置できます。1 つの条件が失敗すると、ルールは実行を停止します。例外は IF/ELSE 条件です。
アクション
アクションはルール チェーンの「実行者」です。課題の編集、通知の送信、サブタスクの作成、監査メッセージの追加など、他にも数多くのタスクを実行できます。アクションによって、Jira と外部システムに変更を加えられます。
ブランチの作成 / 関連する課題
実際のところ、Jira 課題が単独で存在することはほとんどありません。課題はサブタスクを持ったりより大きなエピックのストーリー パートとなったり、さらには特定の関係によってその他の課題に単にリンクしたりできます。
多くの場合、自動化する際は自動化ルールをトリガーしたソース課題だけでなく、そのソース課題に関連する課題にも特定のアクションを適用する必要があります。
Automation for Jira Server では、ブランチ ルール/関連する課題と関連する課題の条件によって、これを非常に簡単にします。
これによって、複雑な課題の関係全体で機能する非常に強力なルールを作成できます。たとえば、親のすべてのサブタスクが解決されていることを確認、または別のプロジェクトのリンクされた課題を同期します。
スマート値
スマート値によって、Jira のほとんどすべての課題データにアクセスできます。たとえば、Slack メッセージを送信して、そのメッセージに課題キーと課題の要約を含めることをお勧めします。次によって、キーまたは要約にアクセスして出力できます。
{{issue.key}} - {{issue.summary}}スマート値の使用方法に関する詳細をご確認ください。
ルール アクター
ルール アクターは、ルール実行者です。他の Jira ユーザーと同様に、ルール アクターはアクションの完了やルールのトリガーに必要な権限を持っている必要があります。たとえば、ルールに「課題にコメント」アクションが含まれている場合、ルール アクターは「コメントを追加」権限を持っている必要があります。持っていないと、ルールはエラーになります。
特定のチーム メンバーではなくルールに再利用できる適切な権限を持つ「自動ボット」や「David Bowie ボット」などのルール アクターを作成するのがベスト プラクティスです。そうすることで、チーム メンバーが離席または宝くじに当選して休暇を取っても、ルールは引き続き実行されます。
ルール アクターを変更するには、ルールの詳細に移動します。
ルールのオン/オフ
ルールの現在のステータスは、ヘッダーの色付きバッジに表示されます。
- 有効 ルールは現在有効です。
- 無効: ルールは現在使用されていません。
- 下書き ルールに未公開の変更があります。
ルール作成プロセスの最後 (そして最高な部分) は、命名して実行することです。作成後すぐにはルールを実行しない場合は、ルールのリストまたは詳細にある切り替えボタンで、ステータスを無効に変更できます。
ルールを有効にすると、各アクティビティを監査ログで追跡できます。
ルールの編集
ルールチェーン ビュー (左側) では、ルールチェーンに向けて、またはルールチェーンに沿ってコンポーネントをドラッグ & ドロップできます。また、コンポーネント間のルールチェーンをクリックして、新しいコンポーネントを追加できます。
ルール詳細ビュー (右側) では、対象となるプロジェクトや名前など、ルールの詳細を編集できます。
ルール トリガーを許可 - 他のルールをトリガーするルール
初期設定では、あるルール内のアクションは別のルールをトリガーしません。これは、ルール実行ループを回避するためです。この設定を変更するには [ルール トリガーを許可] チェックボックスをオン/オフします。別のルールへの応答としてこのルールを実行する必要がある場合にのみ、これを有効にしてください。
ルール コンポーネントを編集する各段階で、[保存] ボタンによって変更を保存します。[キャンセル] を選択して選択したルール コンポーネントを前の状態に戻すことで、変更を元に戻せます。これは、ルール全体に対するすべての変更をキャンセルするわけではなく、選択したコンポーネントへの変更のみをキャンセルします。
変更を完了したら「公開」または「破棄」できます。公開されると新しいルールはアクティブになりますが、ステータスはルールの編集を開始したときのままです。つまり、有効だった場合は有効、無効だった場合は無効のままになります。
ルール スコープ
初期設定では、プロジェクトとグローバルの両管理者がルールを作成して編集できます。ただし、グローバル管理者は、グローバル設定でルールを編集できるプロジェクト管理者をさらに制限できます。特に大企業では、ルールの作成者を特定グループのユーザーに制限しておくことをお勧めします。
ルールは次のスコープで作成されます。
| 範囲 | 説明 | 権限 - 作成/編集 |
|---|---|---|
| グローバル | ルールはすべてのプロジェクトの課題に対して実行されます。 | グローバル管理者 |
| 複数のプロジェクト | 選択したプロジェクトの課題に対してルールが実行されます。 | グローバル管理者 |
| プロジェクト固有 | プロジェクト 1 つのみの課題に対してルールが実行されます。 | プロジェクトとグローバルの各管理者 |
この記事では、プロジェクト自動化のための権限について説明します。
[ルールの詳細] の [プロジェクトに制限] 設定を更新することで、特定のプロジェクトのスコープを変更できます。
監査ログ
各ルールには監査ログがあり、ルールがいつトリガーされたか、実行後の最終結果、適用された可能性のあるアクションを確認できます。監査ログは、個々のルール、プロジェクト全体、またはグローバル レベルで表示できます。監査ログのレビューは、ルールのデバッグに対する最も有益な方法の 1 つです。
