robotsnoindex

ベスト プラクティスのガイドラインに従うことで、自動化ルール設定のパフォーマンスと管理のしやすさを最適化できます。

管理性

ルールを作成する前に計画を立てる

ルールを事前に計画しておくと、必須のルールや、条件を使用してルールを組み合わせる箇所を慎重に考える時間が得られます。

ワークフローと発生させたいアクションから始め、そのアクションをトリガーするイベントにさかのぼります。課題に対する顧客のフィードバック コメントすべてにメールを送信しますか? それとも優先度の高い課題に関するメールのみに返信しますか?

ビジネスと業務プロセスに合わせた自動化計画

自動化ルールはビジネスと業務プロセスの効率向上に役立つように設計されています。自動化ルールと、ビジネスと業務プロセスは適合するようにしてください。自動化ルールの確認は、ビジネスと業務プロセスの確認と同時に行います。

パフォーマンス

特定のプロジェクトにのみルールを制限する

できるだけ多くのルールを "グローバル" から "プロジェクト" に変換します。ルールを単一プロジェクトに適用するのか、それとも複数のプロジェクトにまたがって実行するのかを検討します。変換すると、一致しないルールがあるプロジェクトがフィルターによってイベントから排除されるため、ルールの効率性が向上します。その結果、実行キューに並ぶルールの数が減少します。

ルールの結合

ルールは単独でも十分機能しますが、組み合わせて使うこともできます。複数の現在のルールに対して同じルールを使えるのでしょうか。たとえば、現在のルールで分岐するルールがあり、その下で条件とアクションを実行するとします。

適切なトリガーを選択する

たとえば、フィールド値の変更課題の更新よりもはるかに無駄がなく、特定の操作に制限するのに最適です。課題作成でのみアクションを実行したい場合は、トリガーでこのオプションを選択するようにします。

ルール チェーンで可能な限り早く比較条件を使う

ルール内のできるだけ早い段階で課題フィールド条件 (またはより強力な条件が必要な場合は高度な比較条件) を使用します。ルールの始めにこれらの条件をチェーンし、すべての不要な課題を可能な限り早く除外することが理想的です。 

処理量の多いチェックをルール チェーンの下位に移動する

課題フィールド条件はもっとも簡単に実行できます。その次に簡単なのが詳細比較条件、および JQL 条件です。たとえば、status = Done (JQL 条件) を確認するには、{{issue.status.name}} = Done (詳細比較条件) の場合よりも多くの処理が必要となります。

詳細比較および JQL 条件の使用は、できるだけ避けるか、チェーンの後半で使用します。

条件の詳細を確認する

ブランチ ルールは慎重に使う

ブランチ ルールは絶対に必要な場合のみ使用します。たとえば、現在の課題向けのブランチ ルールは新しいプロセスを生み出します。ルールを組み合わせる場合は良いオプションですが、目的を果たさない場合はパフォーマンスに悪影響を及ぼしかねません。