AWS CodePipelineでテストを自動化!CIの安全運用方法はこれだ!

AWS CodePipelineでテストを自動化!CIの安全運用方法はこれだ!

こんにちは!

今回は、AWS の CodePipeline のビルドフェーズ(本記事では CodeBuild)で実行されるテストについて安全な運用方法を解説していきます!ぜひ参考にしてみてください!

想定する読者

  • CodePipeline への理解を深めたいヒト
  • CodeBuild への理解を深めたいヒト
  • AWS環境におけるCI部分の自動化について知りたいヒト

はじめに

みなさま、CI/CD 環境は構築されてますか?

本記事では CodeBuild を利用した CI 部分について解説していきます。運用方法なども交えて解説していきます。ぜひ参考にしてください!

CI 部分の構築

CodeBuild を使いこなすには BuildSpec について理解することが不可欠です。BuildSpec とは、ビルドの仕様を記述した YAML ファイルのことを指しています。このファイルに様々な命令を記述することで、ビルドやテストの自動化を実現することができます。

こちらがビルドやテストを自動化した BuildSpec ファイルとなります。

version: 0.2
phases:
  install:
    runtime-versions:
      nodejs: 12
    commands:
      - yarn install
  build:
    commands:
      - yarn build:${STAGE}
      - yarn test
reports:
  jest_reports:
    files:
      - 'jest-results.xml'
    file-format: JunitXml
    base-directory: "reports/test"
artifacts:
  files:
    - '**/*'
  base-directory: dist

上記は、シンプルに yarn でパッケージをインストールしたあと、環境に合わせたビルドとテストを行なっています。ここに記載されている環境変数は CodePipeline にて設定が可能です。

セクションとして必要なパラメータは、大きく分けて3つのものになります。

  • phases: 実行されるコマンド
  • reports: テスト結果を出力する場所
  • artifacts: ビルドしたソースコードの出力

安全な運用を行うためにまずはこれらの役割を把握しておきましょう。

phases

このセクションでは以下のようなパラメータを設定することができます。

パラメータ実行されるタイミング
installインストール時
パッケージのインストールのときのみに使用する
pre_buildビルド前
例:ECRにサインインするなど
buildビルド中
例:Mocha、RSpec、または sbt を実行するなど
post_buildビルド後
例:Dockerイメージのプッシュ

BuildSpec で必ず記述するのは install や build の部分になります。この部分でパッケージなどをインストールしたりビルドしたりします。記述方法は以下のような形です。

phases:
  install:
    runtime-versions:
      nodejs: 12
    commands:
      - yarn install
  build:
    commands:
      - yarn build:${STAGE}
      - yarn test

install の部分ではランタイムを指定する必要があります。コマンドは複数指定することが可能ですので、必要に応じて設定してください。

テストのコマンドは、pre_build か build の部分で実行しましょう。

reports

このセクションでは、テストの結果レポートを出力する設定を行います。Jest の場合だと以下のような記述方法になります。

reports:
  jest_reports:
    files:
      - 'jest-results.xml'
    file-format: JUNITXML
    base-directory: "reports/test"

ほかのテストフレームワークにも対応しておりますので、こちらに関しては AWS のドキュメントを参考にしてください。

なお、レポートはマネジメントコンソールで確認が可能です。

ビルド > レポートグループ > 対象のレポートグループ

artifacts

このセクションでは、ビルドを出力する場所について記述するところになります。SPA の場合、デプロイ先は S3 になるかと思いますが、その場合に artifacts を記述し、デプロイフェーズの準備をします。

記述方法は以下のようになります。

artifacts:
  files:
    - '**/*'
  base-directory: dist

上記はすべてのファイルを出力しております。base-directory は出力したアーティファクトを置くディレクトリを指定しております。

こちらのテンプレートはビルドしたファイルやディレクトリをすべてデプロイする定型のパターンになりますので、使い回すことが可能です。

アーティファクトの出力先は CodePipeline 作成時に作成された、アーティファクト用の S3 バケットとなります。S3 バケットを確認すると以下のようなものがありますので、中を見るとアーティファクトが出力されております。

なお、CloudFormation で CodePipeline を構築する場合は、アーティファクト用の S3 バケットを作成するテンプレートが必要となるため、注意してください。

テンプレートは以下のようになります。

Resources:
  CodepipelineBucket:
    Type: 'AWS::S3::Bucket'
    Properties:
      BucketName: ArtifactBucket

  CodePipeline:
    Type: AWS::CodePipeline::Pipeline
    Properties:
      Name: sample-pipeline
      RoleArn: !GetAtt CodepipelineServiceRole.Arn
      ArtifactStore: 
        Location: !Ref CodepipelineBucket
        Type: S3
      ...

パイプラインファーストという考え方

CI 部分に限らず、CI/CD のパイプラインを構築および運用する上で、大切となるパイプラインファーストという考え方をご紹介します。

パイプラインファーストとは、プロジェクトで一番最初に作るべきは CI/CD パイプラインという考え方です。これは最小限のものでも CI/CD パイプラインを準備しておくことによってデプロイの容易性をあらかじめ高め、開発環境に対して長期的な投資をしようという考え方です。(パイプラインファーストの概念についてはこちらを参考にしています)

後回しになりがちな CI/CD パイプラインの構築を、プロジェクトのスタート段階で準備しておくことは開発効率を高める上でとても低リスクな投資と言えるでしょう。

本記事ではじめに例としてあげたシンプルなテンプレートでもいいので、まずは CI 部分を作成し、そのあとに簡易的な CD 部分を構築してパイプラインを作成しておくのがベストプラクティスと言えるでしょう。

CodeBuild の運用方法

最後に CodeBuild の安全な運用方法を考えていきます。

パイプラインファーストの考え方に基づいて、プロジェクトの初期段階ではシンプルな BuildSpec ファイルを作成しましょう。パッケージをインストールしてビルドするだけのものでOKです。

そのあとに、手動でやっているコマンドを徐々にスクリプトに追加していきましょう。自動化できない複雑なことが必要になる場合は、ほかに方法がないのか改めて考えてみるのがベターです。

デプロイ容易性を高める=開発効率を上げることおよびエンジニアのストレスを下げることに繋がりますので、自動化できることを前提にテストやビルドフェーズで利用するコマンドを組み立てていきましょう。シンプルに保つことが大事です。

そして柔軟性を保つために、いくつかの変数を取り入れましょう。本記事で紹介したビルド部分のテンプレートには、変数が使われています。この変数は CodePipeline や BuildSpec ファイルにて設定ができますので、ぜひ活用してみてください。Secrets Manager などに格納している文字列を利用することもできますので、詳細はリファレンスなどで確認してみてください。 

関連記事

まとめ

安全な運用を心がける上で、CI/CD パイプラインを早めに構築することはとても重要です。プロジェクトがまだ複雑になっていないときにこそ、準備をしておきましょう。本記事を参考にぜひ、CodePipeline や CodeBuild を活用していただければ幸いです。

このブログでは、AWS の記事をどんどん公開しておりますので、ご興味のある方はほかの記事もご覧いただければと思います。

AWS に関する開発は、お気軽にお問い合わせください。