ユニフォームネクスト株式会社Publicationへの投稿
🚰

CDK 初挑戦で CodePipeline を改善した記録

Ibuki Kamo
に公開
AWS
CodePipeline
tech

はじめに

こんにちは！最近 AWS を触り始めて、その難しさと楽しさの両方を感じている🦆です。

現在、AWS CDK と CodePipeline を使って CI/CD 環境を構築・運用しています。
今回、より確実に品質を担保できるパイプラインを目指して、テストステージの統合による改善を行いました。
この記事では、実装の詳細と学んだことを共有します。

改善前の構成

当初は以下の3つの CodePipeline を独立して運用していました。

  • フロントエンド用パイプライン
  • バックエンド用パイプライン
  • テストコード用パイプライン

この構成では、テストが独立したパイプラインで実行されるため、
テストが失敗してもデプロイに影響しない構成になっていました。

改善の方針

より堅牢な CI/CD を実現するため、以下の方針で改善を進めました。

  • テストステージをフロントエンドパイプラインに統合
  • テスト失敗時は後続のビルド・デプロイステージに進ませない
  • 不要になったテスト専用パイプラインの削除

CodePipeline の修正で学んだこと

基本概念

  • CDK（Cloud Development Kit）
    • コードで AWS リソースを構築できるフレームワーク。
  • CodePipeline
    • AWS の CI/CD サービス。ソースコードの変更から、テスト・ビルド・デプロイまでの一連の流れを自動化できる。

主な構成要素

  • App
    • AWS CDK の最上位層。複数のスタックの依存関係などを定義する。
  • スタック（Stack）
    • リソースをまとめてデプロイする単位。1つの CloudFormation スタックに変換される。
  • コンストラクト（Construct）
    • CDK の基本的な構成単位。AWSリソースや複数のリソースをまとめた部品を定義し、スタック内で組み合わせて使用する。
  • ステージ（Stage）
    • CodePipeline の中の論理的な区分。ソース、ビルド、テスト、デプロイなど、ソフトウェアのリリースプロセスにおける段階を表す。
      （補足：ソースステージはパイプラインの最初のステージで、アプリケーションのソースコードや設定ファイルを取得する段階）
  • クラス（Class）
    • CDK でスタックやリソースを定義する単位。再利用や構成管理を容易にする。

実際の流れ

  1. フロントエンドパイプラインの定義を確認
    まず、フロントエンド用 CodePipeline を定義している CDK スタックを確認しました。
    このスタックでは、以下のような流れでステージが定義されていました。
pipeline.addStage({
  stageName: 'Source',
  actions: [sourceAction],
});

pipeline.addStage({
  stageName: 'Build',
  actions: [buildAction],
});

pipeline.addStage({
  stageName: 'Deploy',
  actions: [deployAction],
});

  1. どこにテストステージを追加するか決める
    次に、テストをどこに組み込むかを考えました。

    • テストは、ビルド前に実行したい
    • 既存のビルド・デプロイの定義は極力変更したくない

    そこで、ソースステージ直後にテストステージを追加する 方針にしました。

  2. テストステージを追加する
    方針が決まったので、フロントエンドパイプラインにテスト用のステージを追加しました。
    具体的には、Source の直後に Test ステージを挿入します。

pipeline.addStage({
  stageName: 'Source',
  actions: [sourceAction],
});

// テストステージを追加
pipeline.addStage({
  stageName: 'Test',
  actions: [testAction],
});

pipeline.addStage({
  stageName: 'Build',
  actions: [buildAction],
});

pipeline.addStage({
  stageName: 'Deploy',
  actions: [deployAction],
});

  1. ステージ全体の流れを整理
    テストステージを追加したことで、パイプライン全体の流れは以下のようになりました。
    1 Source
    　リポジトリの変更を検知し、ソースコードを取得
    2 Test
    　テストコードを実行
    　失敗した場合はここでパイプラインが停止
    3 Build
    　テストを通過したコードのみをビルド
    4 Deploy
    　ビルド成果物を本番（または検証）環境へデプロイ

  2. テスト専用パイプラインの削除
    フロントエンドパイプラインにテストを統合したことで、
    これまで使っていた テスト専用の CodePipeline は不要になったので削除しました。

最後に

テストコードの重要性を改めて実感しました。
テストが確実に実行される環境を整えることで、リリース時のリスクを減らし、品質をしっかり担保できます。

今回、初めて CDK を使って CodePipeline の修正に挑戦し、実際に手を動かすことで理解が大きく深まりました。
今後も AWS に積極的に触れ、アプリケーションだけでなくインフラまで幅広く対応できるようになりたいです！

ユニフォームネクスト株式会社
ユニフォームネクスト株式会社Publication

ユニフォームネクストは、制服や作業服の販売を通して、 生き生きと働く人を増やし、企業やお店の発展につなげられるようお手伝いをする会社です。 お客様により良いサービスを提供するために、システムエンジニアなどのIT人材を積極的に採用中。 システムの自社開発や新規サービスの立ち上げなど新しいことにチャレンジしてます。

Discussion