Amazon CodeCatalyst は新規のお客様には提供されなくなりました。既存のお客様は、通常どおりサービスを引き続き使用できます。詳細については、「[CodeCatalyst から移行する方法](migration.md)」を参照してください。
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# ワークフロー実行の承認の必須化
ワークフロー実行を続行する前に承認を必須とするように構成できます。これを行うには、ワークフローに**承認**[ゲート](workflows-gates.md)を追加する必要があります。*承認ゲート*によって、1 人または複数のユーザーが CodeCatalyst コンソールで 1 つ以上の承認を送信するまで、ワークフローが進まなくなります。全員の承認が下りると、ゲートの「ロックが解除」されてワークフロー実行を再開できます。
ワークフローで**承認**ゲートを使用して、開発チーム、オペレーションチーム、リーダーシップチームに、より広範な対象者にデプロイされる前に変更を確認する機会を提供します。
ワークフロー実行の詳細については、「[ワークフローの実行](workflows-working-runs.md)」を参照してください。
**Topics**
+ [承認ゲートのロックを解除するにはどうすればよいですか?](#workflows-approval-conditions)
+ [「承認」ゲートを使用するケース](#workflows-approval-when)
+ [承認を行うことができるユーザーは誰ですか?](#workflows-approval-who)
+ [承認が必須であることをユーザーに通知するにはどうすればよいですか?](#workflows-approval-notify-methods)
+ [ワークフロー実行が開始されないようにするために「承認」ゲートを使用できますか?](#workflows-approval-prevent)
+ [キュー実行モード、優先実行モード、並列実行モードにおけるワークフロー承認の仕組みはどのようになっていますか?](#workflows-approval-run-mode)
+ [例: 「承認」ゲート](workflows-approval-example.md)
+ [「承認」ゲートの追加](workflows-approval-add.md)
+ [承認通知の構成](workflows-approval-notify.md)
+ [ワークフロー実行の承認または却下](workflows-approval-approve.md)
+ [「承認」ゲート YAML](approval-ref.md)
## 承認ゲートのロックを解除するにはどうすればよいですか?
**承認**ゲートのロックを解除するには、次の条件が*すべて*満たされている必要があります。
+ **条件 1**: 必要な数の承認が下りている。必要な承認数は変更可能で、各ユーザーは承認を 1 回だけ送信できます。
+ **条件 2**: ゲートがタイムアウトになる前にすべての承認が下りている。ゲートはアクティブ化されてから 14 日後にタイムアウトになります。この期間は変更できません。
+ **条件 3**: 誰もワークフロー実行を却下していない。一度でも却下拒否されるとワークフロー実行に失敗します。
+ **条件 4**: (優先実行モードを使用している場合にのみ該当) 対象の実行が後続の実行よりも優先されない。詳細については、「[キュー実行モード、優先実行モード、並列実行モードにおけるワークフロー承認の仕組みはどのようになっていますか?](#workflows-approval-run-mode)」を参照してください。
いずれかの条件が満たされない場合、CodeCatalyst はワークフローを停止し、実行ステータスを **[失敗]** (**条件 1** ～ **3** の場合) または **[優先済み]** (**条件 4** の場合) に設定します。
## 「承認」ゲートを使用するケース
通常、アプリケーションやその他のリソースを本番サーバー、または品質標準を検証する必要がある環境にデプロイするワークフローで**承認**ゲートを使用します。本番環境にデプロイする前にゲートを配置することで、レビュアーは新しいソフトウェアリビジョンが一般公開される前にそれを検証できます。
## 承認を行うことができるユーザーは誰ですか?
プロジェクトのメンバーであり、**コントリビューター**または**プロジェクト管理者**のロールを持つユーザーが承認を行うことができます。プロジェクトのスペースに属する、**スペース管理者**ロールを持つユーザーも承認を行うことができます。
**注記**
**レビュアー**ロールを持つユーザーは承認を行うことができません。
## 承認が必須であることをユーザーに通知するにはどうすればよいですか?
承認が必須であることをユーザーに通知するには、以下を行う必要があります。
+ CodeCatalyst から Slack 通知を送信します。詳細については、「[承認通知の構成](workflows-approval-notify.md)」を参照してください。
+ **[承認]** ボタンと **[却下]** ボタンがある CodeCatalyst コンソールのページに移動し、そのページの URL を承認者宛ての E メールまたはメッセージングアプリケーションに貼り付けます。このページへの移動方法の詳細については、「[ワークフロー実行の承認または却下](workflows-approval-approve.md)」を参照してください。
## ワークフロー実行が開始されないようにするために「承認」ゲートを使用できますか?
はい、ただし条件があります。詳細については、「[ワークフロー実行が開始されないようにするためにゲートを使用できますか?](workflows-gates.md#workflows-gates-prevent)」を参照してください。
## キュー実行モード、優先実行モード、並列実行モードにおけるワークフロー承認の仕組みはどのようになっていますか?
キュー実行モード、優先実行モード、または並列実行モードを使用する場合、**承認**ゲートは[アクション](workflows-actions.md)と同様に機能します。これらの実行モードの詳細については、「[キュー実行モードについて](workflows-configure-runs.md#workflows-configure-runs-queued)」、「[優先実行モードについて](workflows-configure-runs.md#workflows-configure-runs-superseded)」、「[並列実行モードについて](workflows-configure-runs.md#workflows-configure-runs-parallel)」の各セクションを読むことをお勧めします。各モードの基本事項を理解できたら、このセクションに戻って、**承認**ゲートが存在するときに各実行モードがどのように機能するかを確認してください。
**承認**ゲートが存在する場合、実行は次のように処理されます。
+ [キュー実行モード](workflows-configure-runs.md#workflows-configure-runs-queued)を使用している場合、現在ゲートで承認を待っている実行の後ろで実行が順番待ちをすることになります。そのゲートのロックが解除されると (つまり、すべての承認が下りると)、キュー内の次の実行がゲートに進んで承認を待ちます。このプロセスは、キューに入れられた実行がゲートを通じて 1 つずつ処理されることで続行されます。[Figure 1](#figure-1-workflow-queued-run-mode-ma) はこのプロセスを示しています。
+ [優先実行モード](workflows-configure-runs.md#workflows-configure-runs-superseded)を使用している場合、動作はキュー実行モードと同じです。ただし、実行がゲートのキューに蓄積されるのではなく、新しい実行が以前の実行よりも優先 (引き継ぐ) されます。キューはなく、現在ゲートで承認を待っている実行はキャンセルされ、新しい実行が優先されます。[Figure 2](#figure-2-workflow-superseded-run-mode-ma) はこのプロセスを示しています。
+ [並列実行モード](workflows-configure-runs.md#workflows-configure-runs-parallel)を使用している場合、実行は並列で開始され、キューは形成されません。先行する実行がないため、各実行はすぐにゲートによって処理されます。[Figure 3](#figure-3-workflow-parallel-run-mode-ma) はこのプロセスを示しています。
**図 1**: 「キュー実行モード」と**承認**ゲート
**図 2**: 「優先実行モード」と**承認**ゲート
**図 3**: 「並列実行モード」と**承認**ゲート
