こんにちは!
今回は、AWS の CodePipeline のビルドフェーズ(本記事では CodeBuild)で実行されるテストについて安全な運用方法を解説していきます!ぜひ参考にしてみてください!
みなさま、CI/CD 環境は構築されてますか?
本記事では CodeBuild を利用した 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つのものになります。
安全な運用を行うためにまずはこれらの役割を把握しておきましょう。
このセクションでは以下のようなパラメータを設定することができます。
パラメータ | 実行されるタイミング |
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 の部分で実行しましょう。
このセクションでは、テストの結果レポートを出力する設定を行います。Jest の場合だと以下のような記述方法になります。
reports:
jest_reports:
files:
- 'jest-results.xml'
file-format: JUNITXML
base-directory: "reports/test"
ほかのテストフレームワークにも対応しておりますので、こちらに関しては AWS のドキュメントを参考にしてください。
なお、レポートはマネジメントコンソールで確認が可能です。
このセクションでは、ビルドを出力する場所について記述するところになります。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 の安全な運用方法を考えていきます。
パイプラインファーストの考え方に基づいて、プロジェクトの初期段階ではシンプルな BuildSpec ファイルを作成しましょう。パッケージをインストールしてビルドするだけのものでOKです。
そのあとに、手動でやっているコマンドを徐々にスクリプトに追加していきましょう。自動化できない複雑なことが必要になる場合は、ほかに方法がないのか改めて考えてみるのがベターです。
デプロイ容易性を高める=開発効率を上げることおよびエンジニアのストレスを下げることに繋がりますので、自動化できることを前提にテストやビルドフェーズで利用するコマンドを組み立てていきましょう。シンプルに保つことが大事です。
そして柔軟性を保つために、いくつかの変数を取り入れましょう。本記事で紹介したビルド部分のテンプレートには、変数が使われています。この変数は CodePipeline や BuildSpec ファイルにて設定ができますので、ぜひ活用してみてください。Secrets Manager などに格納している文字列を利用することもできますので、詳細はリファレンスなどで確認してみてください。
安全な運用を心がける上で、CI/CD パイプラインを早めに構築することはとても重要です。プロジェクトがまだ複雑になっていないときにこそ、準備をしておきましょう。本記事を参考にぜひ、CodePipeline や CodeBuild を活用していただければ幸いです。
このブログでは、AWS の記事をどんどん公開しておりますので、ご興味のある方はほかの記事もご覧いただければと思います。
AWS に関する開発は、お気軽にお問い合わせください。
スモールスタート開発支援、サーバーレス・NoSQLのことなら
ラーゲイトまでご相談ください
低コスト、サーバーレスの
モダナイズ開発をご検討なら
下請け対応可能
Sler企業様からの依頼も歓迎