AWS CodePipelineによるリリース工程の自動化

アプリケーションの変更を利用者へ届けるには、ソースコードを取得し、ビルドとテストを行い、成果物を環境へ配備する工程が必要です。毎回の作業を人が個別に実施すると、手順の抜けや環境ごとの差が生じやすくなり、どの変更がどのテストやリリースを経たのかを追いにくくなります。

AWS CodePipelineは、ソフトウェア変更がリリースに至るまでの工程を定義し、実行を自動化する継続的デリバリーサービスです。ソース変更を受けて一連の処理を開始し、各段階の状態や結果を可視化します。ビルドそのものやアプリケーションの配備をすべてCodePipelineが実施するのではなく、CodeBuild、CodeDeploy、CloudFormation、外部のソース・テスト・デプロイサービスなどをアクションとして組み合わせます。

パイプラインを構成するステージとアクション

パイプラインは、リリース工程を区切るステージと、各ステージで実行する個々のアクションで構成されます。たとえば、ソース取得、ビルド、テスト、承認、デプロイはアクションの種類です。それらをソース、ビルド、テスト、本番リリースなどのステージに配置し、変更が進む順序を定めます。

ステージは通常、定義された順序で進みます。同じステージ内では、アクションの実行順序を設定できます。順番の異なるアクションは前の処理の完了後に実行し、同じ実行順序にしたアクションは並列に実行できます。たとえば、ビルド完了後に脆弱性検査を行い、その後に異なるOS環境向けのテストを同時に実施する構成が可能です。並列化する場合は、それぞれのアクションが必要とする入力アーティファクトを正しく割り当てます。

ステージの例	主なアクション	目的
ソース	リポジトリやソース保管場所からリビジョンを取得	対象にする変更を決め、後続工程へ入力を渡す
ビルド	CodeBuildなどでコンパイルやパッケージ化	実行可能な成果物を作成する
テスト	CodeBuildや外部テストサービスで検証	単体テスト、統合テストなどの結果を後続への条件にする
承認	手動承認	本番反映などの前に担当者の判断を挟む
デプロイ	CodeDeploy、CloudFormationなどを呼び出す	成果物をテスト環境や本番環境へ展開する

この並びは一例であり、全パイプラインが同じステージ構成を取る必要はありません。テストの種類、複数環境への段階的な展開、承認の要否に合わせて工程を設計します。CodePipelineは工程の順序と接続を管理し、個別の処理は各アクションプロバイダーが行います。

実行トリガーとソースアクション

トリガーはパイプライン実行を開始するきっかけです。リポジトリへの変更を検知する設定のほか、手動で実行を開始する方法もあります。変更を検知したらパイプラインが対象のリビジョンを処理します。リビジョンはソース側の特定の変更状態を指し、どのコミットやソース更新に対してビルド・テスト・デプロイを実行したかを追跡する単位になります。

パイプライン内のSourceアクションは、開始のきっかけそのものではなく、パイプライン実行で使うリビジョンを取得する処理です。外部GitプロバイダーはAWS CodeConnections経由で接続でき、ブランチへのプッシュやプルリクエストなどのイベントをフィルター条件に設定できます。CodeCommitやAmazon S3のソースアクションでは、変更検出にEventBridgeルールやポーリングを使う構成があります。どの変更でも自動起動するとは限らず、プロバイダーとトリガー設定によって起動条件が決まります。

アーティファクトの受け渡しと保存先

アーティファクトは、アクションが処理するファイル群です。Sourceアクションが出力したソース一式をビルドアクションが入力として受け取り、CodeBuildが生成した配布用パッケージをデプロイアクションが入力として使う、といった形で工程をつなぎます。各アクションの入力アーティファクトは、前段で定義された出力アーティファクトと対応させます。必ずしも直前のアクションだけの出力を受け取る必要はなく、ステージ内の並列処理などに合わせて別の出力を後続アクションへ渡すこともできます。

パイプラインのアーティファクトストアには、アクション間で使う入力・出力アーティファクトを保存するAmazon S3バケットを指定します。CodePipelineはアクションの種類に応じてファイルをまとめ、必要な工程へ転送します。一般的なアクションではZIP形式で受け渡されますが、実際の扱いはアクションプロバイダーの仕様に従います。S3ソースアクションを使う場合、そのソースオブジェクトの保管場所とパイプライン用アーティファクトバケットは別の役割です。

アーティファクト名はパイプライン定義の中で入力と出力を対応づける識別子です。S3バケット内に「パイプライン名、ステージ名、アクション名の順でフォルダーが必ず作られる」と考える必要はありません。保存オブジェクトのキー構造を前提にせず、パイプラインのアーティファクト設定とアクション間の宣言で受け渡しを管理します。

たとえば、地域の公共交通ダイヤを配信するAPIを開発し、GitLabのリポジトリをCodeConnectionsで接続するとします。リリースブランチへの変更をトリガーにパイプラインが起動し、Sourceアクションが対象リビジョンを取得します。CodeBuildがAPIをビルドしてテストを実行し、成功したビルド成果物をアーティファクトとして出力します。後続のデプロイアクションはその成果物を入力として受け取ります。テストしたものと同じ成果物を環境間で引き渡せば、各環境向けに再ビルドして内容に差が生まれるリスクを抑えられます。

ビルド、テスト、デプロイを担当するサービス

CodePipelineのステージに置くアクションはAWSサービスだけに限定されません。外部のソース管理、テスト、デプロイツールを利用することもできます。代表的なサービスの役割を区別してください。

サービス	担当する役割
AWS CodePipeline	パイプラインのステージとアクションを編成し、実行状況を管理する
AWS CodeBuild	指定されたビルド環境とビルド仕様でソースをビルド・テストし、成果物を作成する
AWS CodeDeploy	対応するコンピューティング環境へアプリケーションのリビジョンをデプロイする
AWS CloudFormation	テンプレートに基づいてAWSリソースやスタックを作成・更新する
AWS CodeConnections	外部GitプロバイダーとAWSサービスの接続を提供する

CodeBuildを単独のビルドに使うこともできますが、CodePipelineからビルドアクションとして呼び出せば、成功・失敗に応じた後続工程の制御や、出力成果物の受け渡しを一つのパイプラインにまとめられます。テストもビルド仕様に含められますし、統合テスト用の別アクションとして外部サービスへ委ねることもできます。

デプロイ先によって適切なアクションプロバイダーは異なります。CodeDeployはアプリケーションの配備を担当し、CloudFormationアクションはAWSリソースの構成を更新します。ほかにも要件に合うデプロイプロバイダーを選べます。いずれの場合も、CodePipelineが工程を編成する役割と、デプロイを実際に行うサービスの役割は別です。

手動承認でリリースを一時停止する

本番環境への反映を自動で進める前に、人の確認を必須にしたい場合は、承認アクションをステージに配置します。たとえば、テスト環境へのデプロイと動作確認を終えた後、本番デプロイの直前に承認ステージを設けられます。

承認アクションに到達すると、そのパイプライン実行は判断を待って停止します。権限を持つ担当者が承認すると後続アクションへ進み、却下すると実行は先へ進みません。通知を設定して承認者へ知らせることもできます。手動承認は、検証済みの成果物を本番へ昇格させる前に運用上の確認を入れたい継続的デリバリーで使われます。

実行状況と権限を確認する

CodePipelineの実行履歴では、各実行がどのステージやアクションまで進み、どこで成功または失敗したかを確認できます。失敗が発生したときは、まず失敗したアクションとその入力リビジョンを特定し、次に実行を担当するサービス側のビルドログやデプロイ結果を調べます。CodePipelineがワークフローを管理することと、アクションプロバイダーの実行ログを確認することを分けて考えると、原因を追いやすくなります。

IAM権限も役割ごとに分かれます。CodePipelineのサービスロールは、アクションプロバイダーの呼び出しやアーティファクトの入出力に必要なアクセスを持ちます。CodeBuildのサービスロールはビルド処理中に必要なリソースへアクセスし、デプロイサービス側のロールは配備に必要な操作を行います。ロールを混同せず、それぞれの工程が必要とする最小限の権限を設定します。

試験で整理するポイント

• ソース変更を受けてビルド、テスト、承認、デプロイなどの工程を編成するサービスはCodePipelineです。
• ステージは工程のまとまり、アクションは個々の処理です。同じステージ内のアクションを並列にするか順次実行するかは設定で決まります。
• パイプラインを開始するトリガーと、実行時にソースリビジョンを取得するSourceアクションは別の役割です。利用するソースプロバイダーに応じて変更検出やイベントフィルターを設定します。
• 各アクションの出力アーティファクトを後続アクションの入力として対応づけます。パイプラインのアーティファクトストアには通常S3バケットを指定し、工程間で成果物を受け渡します。
• CodePipelineはリリース工程のオーケストレーション、CodeBuildはビルドとテスト、CodeDeployやCloudFormationなどはそれぞれのデプロイ処理を担当します。
• 本番反映前に人の判断が必要な要件では、手動承認アクションを置いて実行を一時停止します。

公式ドキュメント

• AWS CodePipelineとは
• CodePipelineの概念：パイプライン、ステージ、アクション
• CodePipelineの入力・出力アーティファクト
• CodePipelineのアクション構造と実行順序
• CodePipelineのトリガーとフィルタリング
• AWS CodeBuildとは
• AWS CodeDeployとは