AWS CodePipelineのステージとアクション入門 - パイプラインの基本構成要素を理解しよう ​

CodePipelineでアプリケーションを自動でデプロイするとき、「ステージ」と「アクション」という2つの重要な要素があります。これらはパイプラインの核となる部分で、どんな作業をどの順番で実行するかを決める仕組みです。

この記事では、初めてCodePipelineを使う方でも分かるように、ステージとアクションの基本的な考え方と、よく使われる6つのアクションタイプについて図解を交えて説明します。

ステージとアクションの基本的な考え方 ​

まず、ステージとアクションの関係を理解しましょう。これらは建物の建築工程と同じような考え方です。

ステージとは ​

ステージは「工程」のようなものです。例えば「準備する工程」「作る工程」「公開する工程」といった具合に、作業を大きくまとめたグループのことです。

アクションとは ​

アクションは「具体的な作業」のことです。例えば「ソースコードを取得する」「アプリケーションをビルドする」「テストを実行する」といった、実際に行う作業のことです。

6つのアクションタイプを理解しよう ​

CodePipelineでは、6つの異なるアクションタイプを使い分けることで、様々な作業を自動化できます。それぞれどんな役割を持っているのか、分かりやすく説明していきましょう。

1. Sourceアクション - 「材料を集める」作業 ​

Sourceアクションは、パイプラインの最初に実行される「材料集め」の作業です。料理で例えると、冷蔵庫から野菜を取り出すような作業ですね。

どんなことができる？ ​

  • GitHubからソースコードを取得: 開発者が作ったプログラムを取ってくる
  • CodeCommitからソースコードを取得: AWSの中に保存されているプログラムを取ってくる
  • S3から設定ファイルを取得: アプリの設定情報を取ってくる

なぜ重要？ ​

Sourceアクションがないとパイプラインは何も作業できません。材料がなければ料理ができないのと同じで、ソースコードがなければアプリケーションをビルドできないからです。

2. Buildアクション - 「作る・確認する」作業 ​

Buildアクションは、ソースコードから実際に動くアプリケーションを作る作業です。パン作りで例えると、小麦粉と水を混ぜてパンを焼くような工程ですね。

どんなことができる？ ​

  • コードをコンパイル: プログラムを機械が理解できる形に変換する
  • テストを実行: 作ったプログラムが正しく動くか確認する
  • 依存関係の解決: プログラムが必要とする他の部品を準備する
  • 最適化処理: プログラムをより高速に動くように調整する

なぜ重要？ ​

開発者が書いたコードは、そのままでは動きません。Buildアクションによって初めて、実際にユーザーが使えるアプリケーションの形になるのです。

3. Testアクション - 「品質をチェックする」作業 ​

Testアクションは、作ったアプリケーションがちゃんと動くか確認する作業です。新車の検査で、ブレーキやライトが正常に動くかチェックするのと同じですね。

どんなことができる？ ​

  • 機能テスト: ボタンを押したら正しく反応するかチェック
  • セキュリティテスト: 悪い人に攻撃されても大丈夫かチェック
  • パフォーマンステスト: たくさんの人が使っても遅くならないかチェック
  • 品質チェック: コードが読みやすく書かれているかチェック

なぜ重要？ ​

問題のあるアプリケーションを本番環境に公開してしまうと、ユーザーに迷惑をかけてしまいます。Testアクションで事前にチェックすることで、安心してアプリを公開できるのです。

4. Deployアクション - 「公開する」作業 ​

Deployアクションは、テストが完了したアプリケーションを実際にユーザーが使える場所に設置する作業です。本屋さんで新しい本を棚に並べるのと同じような作業ですね。

どんなことができる？ ​

  • ウェブサイトの公開: 作ったウェブサイトをインターネットで見られるようにする
  • アプリケーションの更新: すでに動いているアプリを新しいバージョンに置き換える
  • サーバーの設定: アプリが動くために必要なサーバー環境を準備する
  • 段階的な公開: 一部のユーザーから試してもらって、問題がなければ全員に公開する

なぜ重要？ ​

どんなに素晴らしいアプリケーションを作っても、Deployアクションがなければユーザーは使うことができません。最終的にユーザーの手に届けるための、とても大切な工程なのです。

5. Approvalアクション - 「確認してもらう」作業 ​

Approvalアクションは、重要な作業の前に人間が「本当に実行していいか？」を確認する作業です。手術の前に医師が最終確認をするのと同じような、安全のためのチェックポイントですね。

どんなときに使う？ ​

  • 本番環境への公開前: ユーザーが実際に使う環境に変更を加える前
  • 重要なデータベースの変更前: データが失われる可能性がある作業の前
  • 費用が発生する作業の前: 大きなコストがかかる可能性がある操作の前
  • 緊急時の対応: 問題が発生したときの緊急対応の前

なぜ重要？ ​

自動化はとても便利ですが、時には人間の判断が必要な場面があります。特に本番環境では、ミスが大きな問題につながる可能性があるため、Approvalアクションで最後の安全確認を行うのです。

6. Invokeアクション - 「特別な処理をする」作業 ​

Invokeアクションは、標準的な作業では対応できない「特別な処理」を実行する作業です。コンビニで例えると、通常の商品販売以外に「宅配便の受付」や「チケット販売」といった特別なサービスを提供するようなイメージですね。

どんなことができる？ ​

  • カスタム通知の送信: SlackやTeamsに特別なメッセージを送る
  • 独自のバリデーション: 会社特有のルールに基づいたチェックを行う
  • 外部システムとの連携: 他のシステムにデータを送ったり情報を取得したりする
  • レポートの作成: デプロイ結果をまとめたレポートを自動生成する

なぜ重要？ ​

すべての会社や プロジェクトには、それぞれ独自の要件があります。Invokeアクションを使うことで、標準的な機能だけでは対応できない特別なニーズに応えることができるのです。

アクションの実行順序について ​

パイプラインでは、アクションを順番に実行したり、同時に実行したりできます。これは料理の手順と同じで、「材料を切る」→「炒める」→「盛り付ける」のように順番が決まっているものもあれば、「野菜を切る」と「お米を炊く」のように同時にできるものもあります。

実際のパイプライン例 ​

これまで学んだ6つのアクションタイプを組み合わせると、こんなパイプラインができます：

まとめ ​

この記事では、CodePipelineの基本的な仕組みである「ステージ」と「アクション」について学びました。

覚えておきたいポイント ​

  • ステージ: 作業をグループ分けする「工程」のようなもの
  • アクション: 実際に行う「具体的な作業」のこと
  • 6つのアクションタイプ: それぞれ異なる役割を持った作業の種類

6つのアクションタイプ ​

  1. Source: 材料を集める（ソースコード取得）
  2. Build: 作る・確認する（ビルド・コンパイル）
  3. Test: 品質をチェックする（テスト実行）
  4. Deploy: 公開する（デプロイメント）
  5. Approval: 確認してもらう（承認制御）
  6. Invoke: 特別な処理をする（カスタム処理）

これらの基本を理解することで、CodePipelineを使った自動化の第一歩を踏み出すことができます。次の記事では、承認プロセスについてより詳しく学んでいきましょう。