CodePipeline の概念

AWS CodePipeline で使用される概念と用語を理解しておくと、自動リリースプロセスのモデリングおよび設定が容易になります。ここでは、 CodePipeline を使用する際に知っておかなければならないいくつかの概念を次に示します。

DevOps パイプラインの例については、「」を参照してくださいDevOps パイプラインの例。

では、次の用語が使用されます CodePipeline。

パイプライン

パイプラインは、ソフトウェアの変更がリリースプロセスをどのように通過するかを記述するワークフロー構造です。各パイプラインは一連のステージで構成されています。

ステージ

ステージは、環境を分離し、その環境での同時変更の数を制限するために使用できる論理ユニットです。各ステージには、アプリケーションアーティファクトに対して実行されるアクションが含まれます。ソースコードはアーティファクトの例です。ステージは、ソースコードが構築され、テストが実行されるビルドステージである場合もあれば、コードをランタイム環境にデプロイするデプロイステージの場合もあります。各ステージは、連続または並列のアクションで構成されています。

アクション

アクションは、アプリケーションコードに対して実行される一連の操作であり、アクションがパイプライン内で指定されたポイントで実行されるように設定されます。これには、コード変更によるソースアクション、インスタンスにアプリケーションをデプロイするためのアクションなどが含まれます。たとえば、デプロイステージには、 AWS Lambda や Amazon EC2 などのコンピューティングサービスにコードをデプロイするデプロイアクションが含まれている場合があります。

有効な CodePipeline アクションタイプは、source、build、test、deploy、approval、および ですinvoke。アクションプロバイダーのリストについては、「CodePipeline での有効なアクションタイプとアクションプロバイダー 」を参照してください。

アクションは、直列または並列で実行できます。ステージ内のシリアルアクションとパラレルアクションの詳細については、アクション構造の要件 の runOrder の情報を参照してください。

パイプライン実行

実行は、パイプラインによってリリースされる一連の変更です。各パイプライン実行は一意であり、独自の ID を持ちます。実行は、マージされたコミットや最新のコミットの手動リリースなど、一連の変更に対応します。2 つの実行では、同じ変更セットを異なる時間に解放できます。

パイプラインは同時に複数の実行を処理できますが、パイプラインステージは一度に 1 つの実行のみを処理します。これを行うために、ステージは実行を処理している間ロックされます。2 つのパイプライン実行は、同時に同じステージを占めることはできません。占有ステージに入るのを待つ実行は、インバウンドの実行 を参照してください。インバウンドの実行は、失敗したり、置き換えたり、手動で停止したりする可能性があります。インバウンドの実行の詳細については、「インバウンド実行の仕組み」を参照してください。

パイプラインの実行は、パイプラインのステージを順番に通過します。パイプラインの有効なステータスは、InProgress、Stopping、Stopped、Succeeded、Superseded、Failed です。

詳細については、「」を参照してくださいPipelineExecution。

停止された実行

パイプライン実行を手動で停止して、進行中のパイプライン実行がパイプラインを介して続行されないようにすることができます。手動で停止した場合、完全に停止するまでパイプライン実行には Stopping ステータスが表示されます。次に、Stopped ステータスが表示されます。Stopped パイプラインの実行を再試行できます。

パイプラインの実行を停止する方法は 2 つあります。

• [Stop and wait (停止して待機)]

• [Stop and abandon (停止して中止)]

実行を停止するユースケースおよびこれらのオプションのシーケンスの詳細については、「パイプライン実行の停止方法」を参照してください 。

失敗した実行

実行が失敗した場合、実行は停止し、パイプラインを完全に通過しません。ステータスは FAILED ステータスで、ステージはロック解除されます。より最近の実行が、追いついてロック解除されたステージに入り、ステージをロックすることができます。失敗した実行が置き換えられているか、再試行可能でない場合を除き、失敗した実行を再試行できます。

実行モード

パイプラインを介して最新の変更セットを配信するため、より新しい実行が、パイプラインを経由してすでに実行されている最新ではない実行をパスし、置き換えます。これが発生すると、古い実行は新しい実行に置き換えられます。実行は、ステージ間のポイントである特定の時点で、より最新の実行に置き換えることができます。SUPERSED はデフォルトの実行モードです。

SUPERSEDED モードでは、実行がロックされたステージに入るのを待っている場合、より最近の実行が追いついて置き換えられる可能性があります。より新しい実行はステージのロックが解除されるまで待機し、置き換えられた実行は SUPERSEDED ステータスで停止します。パイプライン実行が置き換えられると、実行は停止し、パイプラインを完全に通過しません。このステージで置き換えられた後に、置き換えられた実行を再試行することはできません。使用可能なその他の実行モードは、PARALLEL モードまたは QUEUED モードです。

実行モードとロックされたステージの詳細については、「」を参照してくださいSUPERSED モードでの実行の処理方法。

ステージの実行

ある ステージの実行 とは、ステージ内のすべてのアクションを完了するプロセスです。ステージ実行の仕組みとロックされたステージの詳細については、 SUPERSED モードでの実行の処理方法 を参照してください。

ステージの有効なステータスは次のとおりです。InProgress、Stopping、Stopped、Succeeded、および Failed。失敗したステージは、再試行不可能でない限り、再試行できます。詳細については、「」を参照してくださいStageExecution。

アクション実行

アクションの実行は、指定されたアーティファクトに対して動作する設定済みアクションを完了するプロセスです。これらは、入力アーティファクト、出力アーティファクト、またはその両方です。たとえば、ビルドアクションでは、アプリケーションのソースコードのコンパイルなど、入力アーティファクトに対してビルドコマンドを実行できます。アクション実行の詳細には、アクション実行 ID、関連するパイプライン実行ソーストリガー、アクションの入出力アーティファクトが含まれます。

アクションの有効なステータスは、 InProgress 、 Abandoned 、 Succeeded、または Failed です。詳細については、「」を参照してくださいActionExecution。

アクションタイプ

アクションタイプは、 で選択できる事前設定されたアクションです CodePipeline。アクションタイプは、その所有者、プロバイダー、バージョン、およびカテゴリによって定義されます。アクションタイプには、パイプライン内のアクションタスクを完了するために使用されるカスタマイズされたパラメータが用意されています。

アクションの種類に基づいてパイプラインに統合できる AWS のサービス や、サードパーティー製品およびサービスの詳細については、「 CodePipeline アクションタイプとの統合」を参照してください。

のアクションタイプでサポートされている統合モデルの詳細については CodePipeline、「」を参照してください統合モデルのリファレンス。

サードパーティープロバイダーが でアクションタイプを設定および管理する方法の詳細については CodePipeline、「」を参照してくださいアクションタイプの使用。

Transitions

トランジション は、パイプライン実行がパイプラインの次のステージに移動するポイントです。ステージのインバウンドトランジションを無効にして、実行がそのステージに入らないようにし、そのトランジションを有効にして実行を継続することができます。無効なトランジションで複数の実行が到着した場合、トランジションが有効になると、最新の実行だけが次のステージに進みます。つまり、トランジションが無効になっている間は、より新しい実行が待機中の実行よりも優先され、トランジションが有効になった後は継続する実行が優先されます。

アーティファクト

アーティファクトとは、パイプラインアクションによって処理されるアプリケーションのソースコード、構築されたアプリケーション、依存関係、定義ファイル、テンプレートなどのデータの集合を指します。アーティファクトは、いくつかのアクションによって生成され、他のアクションによって消費されます。パイプラインでは、アーティファクトは、アクション (入力アーティファクト) によって処理されるファイルのセットまたは完了したアクションの更新された出力 (出力アーティファクト) です。

アクションは、パイプラインアーティファクト bucket. CodePipeline copies アーティファクトを使用してさらに処理するために出力を別のアクションに渡します。アーティファクトストアは、アクションによって取得されます。アーティファクトの詳細については、「入力および出力アーティファクト」を参照してください。

ソースリビジョン

ソースコードを変更すると、新しいバージョンが作成されます。ソースリビジョンは、パイプライン実行をトリガーするソース変更のバージョンです。実行はソースリビジョンを処理します。 GitHub および CodeCommit リポジトリの場合、これはコミットです。S3 バケットまたはアクションの場合、これはオブジェクトバージョンです。

指定したソースリビジョン (コミットなど) でパイプライン実行を開始できます。実行は指定されたリビジョンを処理し、実行に使用されたはずのリビジョンをオーバーライドします。詳細については、「ソースリビジョンオーバーライドでパイプラインを開始する」を参照してください。

トリガー

トリガーは、パイプラインを開始するイベントです。パイプラインの手動開始などの一部のトリガーは、パイプライン内のすべてのソースアクションプロバイダーで使用できます。パイプラインのソースプロバイダーに依存するトリガーもあります。例えば、 CloudWatch イベントは、イベントルールのターゲットとしてパイプライン ARN CloudWatch が追加された Amazon のイベントリソースで設定する必要があります。Amazon CloudWatch Events は、 CodeCommit または S3 ソースアクションを持つパイプラインの自動変更検出に推奨されるトリガーです。Webhook は、サードパーティーのリポジトリイベント用に設定されるトリガーの一種です。例えば、WebhookV2 は、.com、Enterprise Server、 GitHub GitHub.com、 GitLab GitLab 自己管理型、Bitbucket Cloud などのサードパーティーソースプロバイダーとのパイプラインを開始するために Git タグを使用できるようにするトリガータイプです。パイプライン設定では、プッシュリクエストやプルリクエストなどのトリガーのフィルターを指定できます。Git タグ、ブランチ、またはファイルパスでコードプッシュイベントをフィルタリングできます。イベント (オープン、更新、クローズ）、ブランチ、またはファイルパスでプルリクエストイベントをフィルタリングできます。

トリガーについての詳細は、「でパイプラインを開始する CodePipeline」を参照してください。Git タグをパイプラインのトリガーとして使用する手順を説明するチュートリアルについては、「チュートリアル: Git タグを使用してパイプラインを開始する」を参照してください。

可変

変数は、パイプライン内のアクションを動的に設定するために使用できる値です。変数はパイプラインレベルで宣言したり、パイプライン内のアクションによって出力したりできます。変数値はパイプラインの実行時に解決され、実行履歴で確認できます。パイプラインレベルで宣言した変数は、パイプライン設定でデフォルト値を定義するか、特定の実行に応じて上書きすることができます。アクションによって出力された変数の値は、そのアクションが正常に完了した後に使用可能になります。詳細については、「可変」を参照してください。