自動化の基本
Atlassian Cloud 製品における自動化の一般的なコンセプトとベスト プラクティスを説明します。
インスタンスのパフォーマンスを保つために、以下の自動化サービスの制限が適用されています。
要約 | limit | 制限に違反する場合 |
---|---|---|
ルールのコンポーネント数 | 65 | 1 つのルールに 65 を超える条件、ブランチ、アクションが含まれる |
各アクションの新規サブタスクの数 | 50 | ルールによって、50 を超えるサブタスクの作成を実行します。 |
検索される課題 | 1,000 | スケジュールされた JQL 検索のうち、最適化が不十分で返される課題が1,000 件を超えるもの |
同時に実行できるスケジュール済みのルール | 1 | 実行に 5 分以上かかるアクションが、5 分おきにスケジュールされたルール。このルールの同時実行は 1 つのみ許可します。 |
ルールの関連項目 | 5,000 | ルールを 1 件実行して取得できる項目数を定義します。 たとえば、スケジュールされたトリガーが 100 件の課題を取得し、続いて関連ブランチが課題あたり 10 件のサブタスクを取得する場合、100 x 10 = 1000 件の関連項目がこの制限に追加されます。 この上限に達したルールは無効化され、今後は実行できなくなります。 |
グローバル レベルでキューに入れられているアイテム数 | 50000 | ルールによってキューに入れられたアイテムと同様ですが、グローバル レベルの Jira インスタンスで進行中のルールに適用されます。 |
*日次の処理時間 | 12 時間あたり 60 分 | たとえば、ルールで動作の遅い外部システムと通信する場合はこのケースに当てはまる可能性があります |
ループ検知 | 10 | 実行が停止されループとしてマークされるまでに、ルール自体 (または他のルール) をどれだけ速く連続でトリガーできるかを制御します。 |
24 時間でメール 100 通。 この制限は Jira Cloud の Free エディションとトライアル ライセンスにのみ適用されます。 |
| |
課題検索アクション (Jira Automation) | 100 件の課題 | 課題検索アクションに JQL クエリを入力すると、最初の 100 件の課題のみが使用されます。 |
ブランチがルール実行ごとに取得できるアイテムの数。 |
| たとえば、ルール ブランチに 150 を超える項目を返す CQL クエリが含まれている場合、ルールは最初の 150 項目に対してのみアクションを実行します。 |
同時に実行できるルールの数 |
異なるプランで複数の製品を利用している場合は、上限のみがカウントされます。 | たとえば、Jira Service Management Enterprise と Jira Cloud Free をご利用の場合、サイトで最大 30 個のルールを同時に実行できます。 |
Atlassian Intelligence のアクション | AI アクション アイテムの生成と AI アクションによる要約を 12 時間あたり 1,000 回使用 |
|
自動化ルールで処理される課題のフィールド制限 | 2000フィールド | これは次のアクションに適用されます。
|
*[サービス制限違反時] トリガーを使用して、日次または毎時の処理制限に近づいた際に通知を送信する自動化ルールを作成できます。
監査ログに次のエラーが含まれている場合は、サービス制限に違反している可能性があります。
監査項目のステータスは "THROTTLED" です。
監査項目には以下が含まれます。
Automation for Jira has exceeded the allowed total processing time for this rule. Maximum allowed processing time over 12 hours is (in seconds):
A JQL search in this automation rule has exceeded the allowed maximum number of issues to retrieve per search. Only the first issues up to the following limit where processed:
ルールがそのサービス制限を超過した場合、エラーについての詳細は監査ログで確認できます。
監査ログの情報を使用すると、ルールが許容可能制限内に収まるようにいくつかの手順を講じることができます。一般的な注意事項は次のとおりです。
スケジュールされたルールの実行間隔を短くします。たとえば、5 分ではなく 1 時間おきにのみルールを実行します。
JQL クエリを制限して関心のある課題のみ検索する。たとえば、課題の更新された時間が一定の範囲内であることを確認します (更新済み > -1 週間として、先週の課題のみ含める)。
各ルールに複数のコンポーネントが必要な場合、自動化ルールを複数のルールに分割します。
数千の課題を編集する必要のある、非常に大きな 1 度限りの操作に対しては、Jira の一括変更機能を使用する。
自動化では、ルール処理用のキューによって、インスタンスのルールの実行が管理されます。パフォーマンスを維持するため、ルールの実行はキューに入れられ、同時に処理されるアイテムの数には上限が設けられています。
自動化ルール ビルダーは強力なため複雑なルール構造を構築できますが、キューに並ぶ項目数が急増する可能性があります。
製品のすべてのルールでこの上限に達すると、自動化ルールは実行されなくなります。
多数の関連課題ブランチを伴い、これらの各課題ブランチが多数の課題とマッチしているルールです。
以下の例では、約 13,000 件のアイテムがキューに入れられることになります。
100 個の課題にマッチするスケジュールされたトリガー
関連課題ブランチが 50 件の課題にマッチする
80 件の課題にマッチする別の関連課題ブランチ
if 条件をシミュレーションする多くの関連課題ブランチを含むルールでも、多数のキュー アイテムが発生します。以下の例では、ブランチの数によっては、結果として 3,500 個以上のアイテムとなります。
トリガー: 課題の更新
関連課題ブランチの JQL タイプがバグであり、課題 1,000 件にマッチする
関連課題ブランチの JQL タイプがタスクであり、課題 500 件にマッチする
関連課題ブランチの JQL タイプが Feature であり、課題 2,000 件にマッチするもの
トリガーまたは関連課題ブランチを使用し、1 つのルールが取得する課題の総数を減らすことをおすすめします。
キューのアイテム数のサービス制限を超えないために、以下のガイドラインを参考にしてください。
実行対象が最小限の課題セットに抑えられるように JQL を使用する。その方法は以下のとおり、いくつかあります。
JQL 検索の内容をできるだけ具体的にする。現在、"進行中" の課題にのみ関心がある場合、単純に type = Task に一致する課題を検索しないでください。このケースでより良い JQL は type = Task and status = "In Progress" です。
[このルールが最後に実行されてから変更された課題のみを含める] オプションを使用する。ルールの多くは、この小さいサブセットで運用するだけでも問題ありません。
関連課題ブランチを条件付きの確認用に作成しない。上の例では、課題のタイプに基づいてマッチを探すために、If/else ブロック条件が使えます。
この内容はお役に立ちましたか?