ワークフロー トリガーについて
イベント（例：コミット作成）は特定の開発ツールを JIRA に統合することでトリガーに使用することができるようになります。
グローバル トランジションへのトリガーの追加は、その影響を十分に理解している方だけが行ってください。追加の結果、グローバル トランジションの対象のステータスに予期せずトランジションされるという問題がよく発生します。たとえば、グローバル トランジションでコードがコミットされたときにトランジションがトリガーされると、「レビュー中」や「完了」などのステータスから「進行中」に不正にトランジションされるという問題が起こる可能性があります。
コミット、ブランチ、プル リクエスト、レビューで Jira 作業項目を参照する
以下のテーブルでは、コミット、ブランチ、プル リクエスト、レビューで、これらのイベントが作業項目のトランジションをトリガーように、Jira 作業項目を参照する方法を説明します (トランジションにトリガーをセットアップしている場合)。
イベント | 手順説明 |
|---|---|
コミットの作成 | コミットメッセージに作業項目キーを含めます。 たとえば、"TIS-1 Initial commit" のようなコミットメッセージは、TIS-1 作業項目を「作業前」から「進行中」に自動的にトランジションします。 |
ブランチの作成 | ブランチを作成する際に、ブランチ名に作業項目キーを含めます。 たとえば、ブランチに "TIS-2-feature" と名前をつけると、TIS-2 作業項目が「作業前」から「進行中」に自動的にトランジションします。 |
マージプルリクエストの作成/再オープン/拒否 | プル リクエストに (コミットメッセージで) 作業項目を参照するコミットが含まれていることを確認します。 たとえば、タイトルが "TIS-3" のプル リクエストを作成すると、"TIS-3" 作業項目が "進行中" から "レビュー中" に自動的にトランジションします。プル リクエストを再オープン、却下、またはマージすると、それに応じて "TIS-3" 作業項目もトランジションします。 |
レビューの開始/拒否/廃棄/クローズ | レビューを作成するときに、作業項目キーをレビュータイトルに含めます。 例えば、レビューに「TIS-4 New story」という名前を付けてレビューを開始すると、TIS-4 の作業項目は自動的に「In Progress（進行中）」から「In Review（レビュー中）」に移行します。レビューを却下、破棄、またはクローズすると、「TIS-4」作業項目も適宜トランジションされます。 |
開発ツールから Jira へユーザをマッピングする
以下のプロセスでは、開発ツールのユーザをワークフロー トリガー用に、Jira ユーザにマッピングする方法を説明しています。これはすべてのイベントに適用されますが、各開発ツールではマッピングに異なるメール アドレスとユーザ名を使用します（以下のプロセスの説明に続く箇条書きを参照してください）。
プロセス： 開発ツールのイベントを初期化するユーザは、まずメールアドレスでマッチングし、その後ユーザ名でマッチングして Jira にマッピングされます。つまり、
一致するメール アドレスを持つ単一の Jira ユーザー — Jira ユーザーとして作業項目を移行します。
一致するメール アドレスを持つ Jira ユーザーがいません — 匿名ユーザーとして作業項目をトランジションします。
Jira で一致するメール アドレスを持つ複数のユーザー — そのユーザー グループ内で一致するユーザー名を見つけてみてください。一致するユーザー名を持つ Jira ユーザーが存在する場合は、その Jira ユーザーとして作業項目をトランジションします。一致するユーザー名がない場合は、匿名ユーザーとして作業項目をトランジションします。
ユーザ マッピングに使用されるメールアドレスとユーザ名
Bitbucket Data Center の場合
イベント | ユーザ マッピングに使用されるメールアドレスとユーザ名 |
|---|---|
すべてのプル リクエスト イベント | プル リクエストを操作するユーザーの Bitbucket Data Center メール・アドレスとユーザー名。 |
作成されたコミット | コミットに関連付けられているメール・アドレスと、そのメール・アドレスがマッピングされている Bitbucket Data Center のユーザー名。メール・アドレスがユーザー名にマッピングされていない場合は、コミットにおける作成者の「名前」が使用されます。 |
作成されたブランチ | Bitbucket Data Center にブランチをプッシュした認証済みユーザーの Bitbucket Data Center メール アドレスとユーザー名。 |
Fisheye または Crucible の場合
イベント | ユーザ マッピングに使用されるメールアドレスとユーザ名 |
|---|---|
作成されたコミット | コミットと FishEye の（メールアドレスがマッピングされる）ユーザ名に関連付けられているメールアドレス。メールアドレスがユーザ名にマッピングされていない場合、コミットから作成者の「名前」が使用されます。 |
作成されたブランチ | このイベントはJira ユーザーにマッピングされていません。これは、作業項目が匿名ユーザーとしてトランジションされることを意味します。 |
すべてのレビュー イベント | レビューを実施する認証済みユーザの Crucible のメールアドレスとユーザ名 |
Bitbucket Cloud の場合
イベント | ユーザ マッピングに使用されるメールアドレスとユーザ名 |
|---|---|
すべてのプル リクエスト イベント | プル リクエストを実行したユーザーのBitbucket メール アドレスとユーザー名。注: GitHub ユーザーは、プロファイルに設定されたメール アドレスで少なくとも 1 つはコミットしている必要があります。そうでない場合、プル リクエストは Jira ユーザーにマッピングできません。これは、作業項目が匿名ユーザーとしてトランジションされることを意味します。 |
作成されたコミット | コミットと Bitbucket の（メールアドレスがマッピングされる）ユーザ名に関連付けられているメールアドレス。メールアドレスがユーザ名にマッピングされていない場合、コミットから作成者の「名前」が使用されます。 |
作成されたブランチ | このイベントはJira ユーザーにマッピングされていません。これは、作業項目が匿名ユーザーとしてトランジションされることを意味します。 |
GitHub の場合
イベント | ユーザ マッピングに使用されるメールアドレスとユーザ名 |
|---|---|
プル リクエストの作成 / プル リクエストのマージ | プル リクエストを実行したユーザーのGitHub メール アドレスとユーザー名。注: GitHub ユーザーは、プロファイルに設定されたメール アドレスで少なくとも 1 つはコミットしている必要があります。そうでない場合、プル リクエストは Jira ユーザーにマッピングできません。これは、作業項目が匿名ユーザーとしてトランジションされることを意味します。 |
作成されたコミット | コミットに関連付けられたメール アドレスと、メール アドレスがマッピングされた GitHub のユーザー名。メール アドレスがユーザー名にマッピングされていない場合、コミットの作成者の "名前" が使用されます。 |
作成されたブランチ | このイベントはJira ユーザーにマッピングされていません。これは、作業項目が匿名ユーザーとしてトランジションされることを意味します。 |
イベントのハンドリングとイベントの制限
ほとんどの場合、開発ツールからのイベントを自動作業項目トランジションに処理することは、シームレスに行われます。ただし、イベントの処理方法やイベントの制限により、作業項目のトランジションに遅延が生じたり、作業項目がまったくトランジションしなかったりする場合があります。
イベント処理 — イベントは、開発ツールが DVCS コネクタまたはアプリリンクを介して Jira に接続するかによって、異なる方法で処理されます。これは、Jira が利用できない場合にイベントが遅延または失われるかどうかに影響する可能性があります。
Bitbucket または GitHub の場合
Bitbucket および GitHub からのイベントはDVCS コネクタ経由で Jira で処理されます。DVCS コネクタは、ウェブブック トリガ同期とスケジュール同期の2つの同期方法で Bitbucket および GitHub からのイベントを処理しています。
Webhook トリガーによる同期：DVCS コネクターは、Bitbucket と GitHub の webhook を使用して、イベントが発生したときに Jira にデータを送信します。これは、イベントを処理するための標準的なメカニズムです。つまり、Bitbucket/GitHub イベントの後、作業項目はほぼ即座に自動的に移行されるはずです。イベント制限：10 ブランチ、100 コミット。
スケジュール同期: イベントの上限: 600 件のブランチ (同期間隔 (分) x 10)、6000 件のコミット (同期間隔 (分) x 100)
同期間隔を減らすと、スケジュール同期のイベントの上限を 600 件のブランチと 6000 件のコミット未満にすることができますが、増やすことはできません。
Bitbucket / GitHub イベントが発生したときに Jira に接続できない場合、イベントは DVCS コネクタによって保存され、次にスケジュールされた同期 (デフォルトでは 60 分ごと) に送られます。これは Webhook トリガーによる同期が失敗した場合のバックアップとなります。
Bitbucket Data Center、Fisheye または Crucible の場合
Bitbucket Data Center と Fisheye/Crucible からのイベントは、アプリリンク経由で処理されます。ただし、Bitbucket Data Center と Fisheye/Crucible は、イベントが送信されることを保証する責任があり、イベントが発生した時点で一度だけイベントを送信します。これは、イベントが送信される際に Jira が利用できない場合、イベントが失われることを意味します。
イベントの上限: 10 件のブランチ。1 回の同期あたり 100 コミット10 件のブランチおよび 100 件のコミットの上限に追加で適用される制限は、作業項目変更イベントの制限 100,000 件があります。たとえば、100 個のコミットのそれぞれが 1,000 個を超える作業項目キーを参照する場合、作業項目の変更制限を超過します。1 回の同期ではイベント 6,000 件までに制限されています。
トリガーと他のワークフロー操作/制約との関連
トランジションが自動で開始される場合、トランジションに設定されているすべての条件、バリデータ、権限が無視されます。
ただし、事後操作はそのまま実行されます。事後操作がユーザーを必要とする場合、匿名ユーザーはそのトランジションを実行できないことに注意する必要があります (上記の「ユーザー マッピング」セクションをご確認ください)。
この内容はお役に立ちましたか?