翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # CodePipeline の概念 で使用される概念と用語を理解すれば、自動リリースプロセスのモデル化と設定が簡単になります AWS CodePipeline。ここでは、 CodePipeline を使用する際に知っておかなければならないいくつかの概念を次に示します。 DevOps パイプラインの例については、「[DevOps パイプラインの例](concepts-devops-example.md)」を参照してください。 CodePipeline では、次の用語が使用されます : **Topics** + [Pipelines](#concepts-pipelines) + [パイプライン実行](#concepts-executions) + [ステージオペレーション](#concepts-stage-executions) + [アクション実行](#concepts-action-executions) + [実行タイプ](#concepts-execution-types) + [アクションタイプ](#concepts-action-types) + [アーティファクト](#concepts-artifacts) + [ソースリビジョン](#concepts-source-revisions) + [トリガ](#concepts-triggers) + [[変数]](#concepts-variables) + [条件](#concepts-conditions) + [Rules](#concepts-rules) ## Pipelines *パイプライン*は、ソフトウェアの変更がリリースプロセスをどのように通過するかを記述するワークフロー構造です。各パイプラインは一連の*ステージ*で構成されています。 ### Stages ステージは、環境を分離し、その環境での同時変更の数を制限するために使用できる論理ユニットです。各ステージには、アプリケーション[アーティファクト](https://docs.aws.amazon.com/codepipeline/latest/userguide/concepts.html#concepts-artifacts)に対して実行されるアクションが含まれます。ソースコードはアーティファクトの例です。ステージは、ソースコードが構築され、テストが実行されるビルドステージである場合もあれば、コードをランタイム環境にデプロイするデプロイステージの場合もあります。各ステージは、連続または並列の*アクション*で構成されています。 ### Transitions *トランジション* は、パイプライン実行がパイプラインの次のステージに移動するポイントです。ステージのインバウンドトランジションを無効にして、実行がそのステージに入らないようにし、そのトランジションを有効にして実行を継続することができます。無効なトランジションで複数の実行が到着した場合、トランジションが有効になると、最新の実行だけが次のステージに進みます。つまり、トランジションが無効になっている間は、より新しい実行が待機中の実行よりも優先され、トランジションが有効になった後は継続する実行が優先されます。 ![\[パイプラインには、アクションを含むステージがあり、無効や有効にできるトランジションによって区切られています。\]](http://docs.aws.amazon.com/ja_jp/codepipeline/latest/userguide/images/pipeline-elements-workflow.png) ### アクション *アクション*は、アプリケーションコードに対して実行される一連の操作であり、アクションがパイプライン内で指定されたポイントで実行されるように設定されます。これには、コード変更によるソースアクション、インスタンスにアプリケーションをデプロイするためのアクションなどが含まれます。たとえば、デプロイステージには、 AWS Lambdaや Amazon EC2 などのコンピューティングサービスにコードをデプロイするデプロイアクションが含まれている場合があります。 有効な CodePipeline アクションタイプは次のとおりです。`source`、`build`、`test`、`deploy`、`approval`、および `invoke`。アクションプロバイダーのリストについては、「[CodePipeline の有効なアクションプロバイダー](actions-valid-providers.md)」を参照してください。 アクションは、直列または並列で実行できます。ステージ内のシリアルアクションとパラレルアクションの詳細については、[アクション構造の要件](https://docs.aws.amazon.com/codepipeline/latest/userguide/reference-pipeline-structure.html#action-requirements) の `runOrder` の情報を参照してください。 ## パイプライン実行 *実行*は、パイプラインによってリリースされる一連の変更です。各パイプライン実行は一意であり、独自の ID を持ちます。実行は、マージされたコミットや最新のコミットの手動リリースなど、一連の変更に対応します。2 つの実行では、同じ変更セットを異なる時間に解放できます。 パイプラインは同時に複数の実行を処理できますが、パイプラインステージは一度に 1 つの実行のみを処理します。これを行うために、ステージは実行を処理している間ロックされます。2 つのパイプライン実行は、同時に同じステージを占めることはできません。占有ステージに入るのを待つ実行は、*インバウンドの実行* を参照してください。インバウンドの実行は、失敗したり、置き換えたり、手動で停止したりする可能性があります。インバウンドの実行の詳細については、「[インバウンド実行の仕組み](concepts-how-it-works.md#how-it-works-inbound-executions)」を参照してください。 パイプラインの実行は、パイプラインのステージを順番に通過します。パイプラインの有効なステータスは、`InProgress`、`Stopping`、`Stopped`、`Succeeded`、`Superseded`、`Failed` です。 詳細については、「[PipelineExecution](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_PipelineExecution.html)」を参照してください。 ### 停止された実行 パイプライン実行を手動で停止して、進行中のパイプライン実行がパイプラインを介して続行されないようにすることができます。手動で停止した場合、完全に停止するまでパイプライン実行には `Stopping` ステータスが表示されます。次に、`Stopped` ステータスが表示されます。`Stopped` パイプラインの実行を再試行できます。 パイプラインの実行を停止する方法は 2 つあります。 + **[Stop and wait (停止して待機)]** + **[Stop and abandon (停止して中止)]** 実行を停止するユースケースおよびこれらのオプションのシーケンスの詳細については、「[パイプライン実行の停止方法](concepts-how-it-works.md#concepts-how-it-works-stopping)」を参照してください 。 ### 失敗した実行 実行が失敗した場合、実行は停止し、パイプラインを完全に通過しません。ステータスは `FAILED` ステータスで、ステージはロック解除されます。より最近の実行が、追いついてロック解除されたステージに入り、ステージをロックすることができます。失敗した実行が置き換えられているか、再試行可能でない場合を除き、失敗した実行を再試行できます。失敗したステージを以前の成功した実行にロールバックできます。 ### 実行モード パイプラインを介して最新の変更セットを配信するため、より新しい実行が、パイプラインを経由してすでに実行されている最新ではない実行をパスし、置き換えます。これが発生すると、古い実行は新しい実行に置き換えられます。実行は、ステージ間のポイントである特定の時点で、より最新の実行に置き換えることができます。SUPERSEDED はデフォルトの実行モードです。 SUPERSEDED モードでは、ロックされたステージに入るまで実行が待機している間に、より新しい実行が追いつき、待機中の実行に置き換わる場合があります。より新しい実行はステージのロックが解除されるまで待機し、置き換えられた実行は `SUPERSEDED` ステータスで停止します。パイプライン実行が置き換えられると、実行は停止し、パイプラインを完全に通過しません。このステージで置き換えられた後に、置き換えられた実行を再試行することはできません。その他の使用可能な実行モードは、PARALLEL モードまたは QUEUED モードです。 実行モードとロックされたステージの詳細については、「[SUPERSEDED モードでの実行の処理方法](concepts-how-it-works.md#concepts-how-it-works-executions)」を参照してください。 ## ステージオペレーション パイプライン実行がステージを通過する場合、ステージは、ステージ内のすべてのアクションを完了するプロセスに入ります。ステージオペレーションの仕組みとロックされたステージの詳細については、「[SUPERSEDED モードでの実行の処理方法](concepts-how-it-works.md#concepts-how-it-works-executions)」を参照してください。 ステージの有効なステータスは次のとおりです。`InProgress`、`Stopping`、`Stopped`、`Succeeded`、および `Failed`。失敗したステージは、再試行不可能でない限り、再試行できます。詳細については、「[ステージ実行](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_StageExecution.html)」を参照してください。ステージは、指定した以前の成功した実行にロールバックできます。ステージは、「[ステージロールバックの設定](stage-rollback.md)」で説明しているように、失敗時に自動的にロールバックするように設定できます。詳細については、「[RollbackStage](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_RollbackStage.html)」を参照してください。 ## アクション実行 *アクションの実行*は、指定された[アーティファクト](https://docs.aws.amazon.com/codepipeline/latest/userguide/concepts.html#concepts-artifacts)に対して動作する設定済みアクションを完了するプロセスです。これらは、入力アーティファクト、出力アーティファクト、またはその両方です。たとえば、ビルドアクションでは、アプリケーションのソースコードのコンパイルなど、入力アーティファクトに対してビルドコマンドを実行できます。アクション実行の詳細には、アクション実行 ID、関連するパイプライン実行ソーストリガー、アクションの入出力アーティファクトが含まれます。 アクションの有効なステータスは、 `InProgress` 、 `Abandoned` 、 `Succeeded`、または `Failed` です。詳細については、「[アクション実行](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_ActionExecution.html)」を参照してください。 ## 実行タイプ パイプラインまたはステージの実行は、標準実行またはロールバック実行のいずれかになります。 標準タイプの場合、実行には一意の ID があり、完全なパイプライン実行になります。パイプラインのロールバックには、ロールバックされるステージと、ロールバックする先のターゲット実行としての以前の成功したステージ実行があります。ターゲットのパイプライン実行は、ステージを再実行するためのソースリビジョンと変数を取得するために使用します。 ## アクションタイプ *アクションタイプ* とは、 CodePipeline で選択できる事前設定済みのアクションです。アクションタイプは、その所有者、プロバイダー、バージョン、およびカテゴリによって定義されます。アクションタイプには、パイプライン内のアクションタスクを完了するために使用されるカスタマイズされたパラメータが用意されています。 アクションタイプに基づいてパイプラインに統合できる AWS のサービス およびサードパーティーの製品やサービスについては、「」を参照してください[CodePipeline アクションタイプとの統合](integrations-action-type.md)。 CodePipeline のアクションタイプでサポートされている統合モデルの詳細については、[統合モデルのリファレンス](reference-integrations.md) を参照してください。 サードパーティープロバイダーが CodePipeline でアクションタイプを設定および管理する方法については、 [アクションタイプの使用](action-types.md) を参照してください。 ## アーティファクト *アーティファクト*とは、パイプラインアクションによって処理されるアプリケーションのソースコード、構築されたアプリケーション、依存関係、定義ファイル、テンプレートなどのデータの集合を指します。アーティファクトは、いくつかのアクションによって生成され、他のアクションによって消費されます。パイプラインでは、アーティファクトは、アクション (*入力アーティファクト*) によって処理されるファイルのセットまたは完了したアクションの更新された出力 (*出力アーティファクト*) です。 アクションは、パイプラインアーティファクトバケットを使用してさらに処理するために、出力を別のアクションに渡します。CodePipeline はアーティファクトストアにアーティファクトをコピーし、このアーティファクトはそこでアクションによりピックアップされます。アーティファクトの詳細については、「[入力および出力アーティファクト](welcome-introducing-artifacts.md)」を参照してください。 ## ソースリビジョン ソースコードを変更すると、新しいバージョンが作成されます。*ソースリビジョン*は、パイプライン実行をトリガーするソース変更のバージョンです。実行はソースリビジョンを処理します。GitHub および CodeCommit リポジトリの場合は、コミットメッセージです。S3 バケットまたはアクションの場合、これはオブジェクトバージョンです。 指定したソースリビジョン (コミットなど) でパイプライン実行を開始できます。実行は指定されたリビジョンを処理し、実行に使用されたはずのリビジョンをオーバーライドします。詳細については、「[ソースリビジョンオーバーライドでパイプラインを開始する](pipelines-trigger-source-overrides.md)」を参照してください。 ## トリガ *トリガー*は、パイプラインを開始するイベントです。パイプラインの手動開始などの一部のトリガーは、パイプライン内のすべてのソースアクションプロバイダーで使用できます。パイプラインのソースプロバイダーに依存するトリガーもあります。例えば、CloudWatch イベントは Amazon CloudWatch のイベントリソースで設定され、イベントルールでターゲットとしてパイプラインの ARN が追加されている必要があります。Amazon CloudWatch Events は、CodeCommit または S3 ソースアクションを使用したパイプラインの自動変更検出に推奨されるトリガーです。Webhook は、サードパーティーのリポジトリイベント用に設定されるトリガーの一種です。例えば、WebhookV2 は、Git タグを使用して GitHub.com、GitHub Enterprise Server、GitLab.com、GitLab self-managed、Bitbucket Cloud などのサードパーティのソースプロバイダーのパイプラインを開始できるようにするトリガータイプです。パイプライン設定では、プッシュリクエストやプルリクエストなどのトリガーのフィルターを指定できます。Git タグ、ブランチ、またはファイルパスでコードプッシュイベントをフィルタリングできます。イベント (オープン、更新、クローズ)、ブランチ、またはファイルパスでプルリクエストイベントをフィルタリングできます。 トリガーについての詳細は、「[CodePipeline でパイプラインを編集する](pipelines-about-starting.md)」を参照してください。Git タグをパイプラインのトリガーとして使用する手順を説明するチュートリアルについては、「[チュートリアル: Git タグを使用してパイプラインを開始する](tutorials-github-tags.md)」を参照してください。 **重要** 30 日以上非アクティブなパイプラインでは、パイプラインのポーリングが無効になります。詳細については、パイプイライン構造リファレンスの「[pollingDisabledAt](pipeline-requirements.md#metadata.pollingDisabledAt)」を参照してください。パイプラインをポーリングからイベントベースの変更検出に移行する手順については、「[変更検出方法](change-detection-methods.md)」を参照してください。 ## [変数] *変数*は、パイプライン内のアクションを動的に設定するために使用できる値です。変数はパイプラインレベルで宣言したり、パイプライン内のアクションによって出力したりできます。変数値はパイプラインの実行時に解決され、実行履歴で確認できます。パイプラインレベルで宣言した変数は、パイプライン設定でデフォルト値を定義するか、特定の実行に応じて上書きすることができます。アクションによって出力された変数の値は、そのアクションが正常に完了した後に使用可能になります。詳細については、「[変数リファレンス](reference-variables.md)」を参照してください。 ## 条件 *条件*内には、評価される一連のルールがあります。条件内のすべてのルールが成功すると、条件は満たされます。満たされない場合は、指定した結果 (ステージを失敗させるなど) を適用するように条件を設定できます。条件はゲートとも呼ばれます。これは、実行がステージに入り、ステージを通過し、通過後にステージを終了するタイミングを指定できるためです。これは、ゲートを閉じて交通の流れを溜め、次にゲートを開いてエリアへの交通の流れを許可することと似ています。条件タイプの結果には、ステージを失敗させることやロールバックすることが含まれます。条件は、これらのアクションがパイプラインステージでいつ発生するかを指定するのに役立ちます。条件は、ランタイムに上書きできます。 条件には 3 つのタイプがあります。入力条件は、「条件のルールが満たされた場合、ステージに入る」かどうかという質問に答えます。実行がステージに入ると、ステージはロックされ、次にルールが実行されます。失敗時の条件では、ステージが失敗すると、ルールが適用され、結果として失敗したステージがロールバックされます。成功時の条件では、ステージが成功すると、続行する前に正常な実行をチェックしてアラームを確認するなどのルールが適用されます。例えば、成功時の条件では、CloudWatchAlarm ルールでデプロイ環境にアラームがあることが検出されると、正常なステージがロールバックされます。詳細については、「[ステージ条件はどのように機能しますか?](concepts-how-it-works-conditions.md)」を参照してください。 ## Rules 条件では、1 つ以上の事前設定済みの*ルール*を使用し、チェックを実行して条件が満たされなかった場合に設定済みの結果を適用します。例えば、アラームステータスとデプロイウィンドウの時間をチェックする入力条件のすべてのルールが満たされると、すべてのチェックに合格した正常なステージがデプロイされます。詳細については、「[ステージ条件はどのように機能しますか?](concepts-how-it-works-conditions.md)」を参照してください。