Jira Service Management の管理者向けの利用開始ガイド
最初に、Jira Service Management の使用を開始する方法を確認します。
この記事では、Jira Service Management Cloud の一部のお客様に段階的に展開されている、Jira Service Management でネイティブに利用できる新しいアラート機能を取り上げています。ご利用のサイトにはまだ表示されていないか、利用できない可能性があります。
継続的インテグレーションの実践には、自動化されたテストとリアルタイムでコードの問題を開発者に警告する通知を伴うコードのマージを繰り返すことが含まれます。Codeship は、これを継続的なデリバリーの実践と組み合わせて、変更が自動テストに合格すると通常のコード デプロイメントを提供します。基本的に、コードが GitHub (または Bitbucket) にプッシュされると、Codeship はその安全なサーバー上でアプリケーションを再構築し、自動テストを実行します。テストが失敗した場合は、メールまたはインテグレーションを通じて開発チームに通知します。
Jira Service Management の Codeship 統合を使用して、Codeship ビルド アラートを Jira Service Management に転送します。Jira Service Management では、オンコール スケジュールに基づいて適切な通知先が決定されます。メール、テキスト メッセージ (SMS)、電話、iOS や Android のプッシュ通知によって通知し、アラートが承認されるかクローズされるまでアラートをエスカレートします。
Codeship でビルド アラートが作成されると、統合を通じて Jira Service Management でアラートが自動的に作成されます。
Codeship は API ベースの統合です。設定は次の手順で行います。
Jira Service Management で Codeship 統合を追加する
Codeship で統合を設定する
双方向統合は Free プランと Standard プランではサポートされていません。他のすべての統合は Free と Standard でチーム レベルでサポートされています。ただし、送信統合を機能させるには、上位のプランにアップグレードする必要があります。Settings (歯車アイコン) > Products (Jira 設定の下) > OPERATIONS からサイト レベルで統合を追加できるのは、Premium プランと Enterprise プランのみです。
統合をチームの運用ページから追加すると、そのチームが統合の所有者になります。つまり、Jira Service Management は、この統合を通じて受信したアラートをチームにのみ割り当てます。
Jira Service Management で Codeship 統合を追加するには、次の手順を実行します。
チームの運用ページに移動します。
左側のナビゲーション パネルで、[統合]、[統合を追加] の順に選択します。
検索を実行して [Codeship] を選択します。
次の画面で、統合の名前を入力します。
オプション: 特定のチームが統合からのアラートを受信するようにする場合は、[Assignee team (担当者チーム)] のチームを選択します。
[続行] を選択します。
この時点で、統合が保存されます。
[統合を設定する手順] セクションを展開し、API URL をコピーします。
この URL は、後ほど Codeship で統合を設定する際に使用します。
[統合をオンにする] を選択します。
統合のために作成したルールは、統合をオンにした場合にのみ機能します。
Codeship と Jira Service Management の統合を設定するには、次の手順に従います。
[プロジェクト設定] > [通知] に移動します。
[追加] > [New notification (新しい通知)] を選択します。
[Webhook] を選択します。
以前に Jira Service Management からコピーした API URL を [URL] に貼り付けます。
通知をトリガーするイベントを選択します。
必要に応じて、フィルタリングするブランチを指定します。
[保存] を選択します。
既存のブランチ (またはブランチ マッチ) にルールをさらに追加できます。通知の特定のルール トリガーを削除するには、無効にするか (トグルを使用)、完全に削除します。
「すべてのブランチ」、名前のブランチ、またはブランチ マッチのいずれかにルールがすべて適用されます。フィールドが空のままの場合、ルールはすべてのブランチに適用されます。さらに、すべてのルールにおいて、通知をトリガーするイベントとして、started (開始)、failed (失敗)、succeeded (成功)、recovered (回復) のいずれかを選択できます。ルールを保存するには、少なくとも 1 つのイベントを選択します。
started (開始): 新しいビルドがトリガーされた場合に通知を送信
failed (失敗): 何らかの理由でビルドが失敗した場合に通知を送信
succeeded (成功): ビルドが正常に終了した場合に通知を送信
recovered (回復): 前のビルドは失敗したものの、現在のビルドは成功した場合に通知を送信
Codeship では Webhook Services を使用してビルド データが送信されます。
JSON
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
{
"build": {
"build_url":"https://www.codeship.com/projects/102xx/builds/97xxxx",
"commit_url":"https://github.com/codeship/docs/
commit/96943xxxxxxxxxx",
"project_id":102xx,
"build_id":97xxxx,
"status":"testing",
# PROJECT_FULL_NAME IS DEPRECATED AND WILL BE REMOVED IN THE FUTURE
"project_full_name":"codeship/docs",
"project_name":"codeship/docs",
"commit_id":"96943dc5xxxxxxxxxxxxxxxxxx",
"short_commit_id":"96xxx",
"message":"Merge pull request #34 from codeship/feature/shallow-clone",
"committer":"beanixxxx",
"branch":"master"
}
}
ステータス フィールドには、次のいずれかの値が含まれます。
initiated: ビルドが新規に開始された場合
error: ビルドが失敗した場合
success: ビルドが成功した場合
stopped: ビルドが停止された場合
waiting: ビルド待ちである場合
ignored: アカウントが月間ビルド制限を超えたためにビルドが無視された場合
blocked: リソースを過剰に消費したためにビルドがブロックされた場合
infrastructure_failure: ビルド VM の内部エラーが原因でビルドが失敗した場合
Codeship の通知管理の詳細をご確認ください。Codeship 統合の詳細をご確認ください。
この内容はお役に立ちましたか?