Jira Cloud 製品のご紹介
Jira Cloud の製品、機能、プラン、および移行の詳細をご確認ください。
GitHub のワークフローとデプロイを Jira 課題にリンクする
GitHub のワークフローとデプロイを Jira にリンクする前に、次のことを行う必要があります。
GitHub for Jira アプリを使用して GitHub を Jira Software サイトに連携すると、GitHub Actions のワークフローとデプロイを Jira Software プロジェクトの課題にリンクできます。GitHub Actions を初めて使用する場合は、最初に GitHub Actions のドキュメンテーション セットを読んでください。
課題キーを使用してデプロイを Jira 課題にリンクする
GitHub デプロイを Jira にリンクするには、コミット メッセージ、ブランチ名、プル リクエストに Jira 課題キーを含める必要があります。
リンクする Jira 課題の課題キー (「DEV-2095」など) を探します。
ブランチ名に課題キーを付けて、リポジトリで新しいブランチをチェックアウトします。例: git checkout -b DEV-2095-<branch-name>。
ブランチへの変更をコミットする際は、コミット メッセージに課題キーを付けます。例: git commit -m "DEV-2095 <summary of commit>"。
プル リクエストを作成する際は、プル リクエストのタイトルに課題キーを使用します。
リンクされたブランチ、コミット、またはプル リクエストでデプロイが実行されると、Jira 課題、ボード、デプロイのタイムラインにデプロイ情報が表示されます。
Jira Software で GitHub ビルドを表示する
GitHub のワークフローは Jira では「ビルド」として表示されます。これらは Jira 課題の開発パネル、Jira ボードの課題カード、リリース ハブに表示されます。
Jira 課題の開発パネルを表示するには、「開発ツールの表示」というプロジェクト権限が必要です。プロジェクト権限のアップデート方法
プル リクエストに関連するコミット メッセージに課題キーが見つかれば、ビルドは自動的に Jira 課題にリンクされます。プル リクエストなしでブランチをマージすると、そのブランチの最後のコミット メッセージだけで Jira 課題キーがチェックされます。
上の図を例として使用して、main ブランチから分岐しているフィーチャー ブランチが 2 つあり、フィーチャー ブランチ (緑のドット) と main ブランチ (青のドット) の両方のすべてのコミットで、コードベースを構築してテストするワークフローがトリガーされるように GitHub Actions が設定されていると仮定します。
コミット メッセージに Jira 課題キー (JIRA-*) を含めることで、関連する Jira 課題に特定のワークフロー実行をリンクできます。以下に例を示します。
ワークフロー実行 #6 は Jira 課題 JIRA-1 と JIRA-2 に関連付けられます。
ワークフロー実行 #7 は Jira 課題 JIRA-1、JIRA-10,、JIRA-11 に関連付けられます。
ワークフロー実行 #2 は Jira 課題 JIRA-1 にのみ関連付けられます。
JIRA-1 と JIRA-2 は両方とも同じプル リクエストの一部であるため、ワークフロー実行 #4 はこれら両方に関連付けられます。
GitHub ワークフローをプル リクエストで実行できるようにするには、プル リクエストのソース ブランチのブランチ名パターンをワークフロー設定で次のように指定する必要があります。
1
2
3
4
5
on:
pull_request:
branches:
- main
- feature**GitHub のデプロイを Jira Software で表示する
GitHub からのデプロイは、Jira 課題の開発パネル、Jira ボードの課題カード、リリース ハブ、およびデプロイ ページのデプロイ タイムラインに表示されます。GitHub Actions ワークフローにデプロイを追加するには、アクション chrnorm/deployment-action@releases/v1 を使って GitHub でデプロイ アクションを作成する必要があります。
Jira 向け GitHub アプリは deployment_status イベントのみをリッスンします。つまり、GitHub のデプロイは次の条件を満たす場合にのみ Jira に表示されます。
デプロイが GitHub のデプロイ作成 API または chrnorm/deployment-action@releases/v1 アクションを使用して作成されています。
デプロイ作成後、デプロイ・ステータス作成 API または chrnorm/deployment-status@releases/v1 アクションを少なくとも 1 回呼び出して、デプロイのステータスをアップデートする必要があります。
Jira 向け GitHub アプリは、デプロイされたブランチをスキャンして、Jira 課題キーを含む新しいコミット・メッセージを探すことで、新しい GitHub デプロイを識別します。
上の図を例に取り、main ブランチから分岐するフィーチャー・ブランチが 2 つあり、main ブランチでプッシュするたびにデプロイがトリガーされるように GitHub Actions が設定されていると仮定します。
コミット・メッセージに Jira 課題キー（JIRA-*）を含めると、対応する Jira 課題に関連するデプロイが表示されます。例:
失敗したデプロイ #6 は Jira の課題 JIRA-1 と JIRA-2 に表示されます
デプロイ #7 は、関連するすべての Jira 課題に表示されます（どのコミットもまだ正常にデプロイされていないため）
デプロイ環境をマッピングする
デプロイ イベントには、アプリがデプロイされた環境の名前が含まれます。Jira 課題に環境の詳細を表示するには、環境が、development、testing、staging、production のいずれであるかを Jira が知る必要があります。Jiraは、環境名に基づいて、デプロイ イベントをマッピングする環境の推測を試行します。たとえば、prod という名前の環境へのデプロイでは、production 環境が想定されます。
他の環境名（英語以外の環境名など）を使用すると、Jira はそれらを未定義の環境として表示します。これを解決するには、.jira/config.yml というファイルをリポジトリのメイン・ブランチに追加し、カスタム環境名を Jira が認識する標準環境名にマッピングすることで、カスタム環境を指定できます。
例を以下に示します。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
deployments:
environmentMapping:
development:
- "dev*"
- "Entwicklung"
- "desenvolvimento"
- "дев"
testing:
- "testes"
- "Test"
- "TST-*"
- "тест"
staging:
- "Pre-Prod"
- "STG-*"
- "staging"
production:
- "Produktion"
- "produção"
- "продакшн"
- "PROD-*"上記の例を使用すると、「TST-3」という名前の環境へのデプロイ・イベントは、testing 環境へのデプロイとして Jira に表示されます。一方、「produção」という名前の環境へのデプロイは、production 環境として Jira に表示されます。
Jira の 4 つの有効な環境タイプのそれぞれに、最大 10 個の glob パターンを指定できます。この設定ファイルを追加すると Jira で環境名を自動的に検出できなくなるため、すべての環境名のパターンを指定する必要があります。
この内容はお役に立ちましたか?