AWS CodeBuildを用いた継続的インテグレーション自動化(その2)

事前準備：セキュリティグループの作成

CodeBuild設定の事前準備として、CodeBuildが実行するビルド環境のコンテナイメージに適用するセキュリティグループを「VPC」サービスで作成しておきましょう。ビルドに必要なソフトウエアや、GitHubへソースコードを取得するための任意のアウトバウンド許可設定があれば、特にインバウンド許可は必要ありません。

CodeBuildの設定

次に、AWSコンソールメニューから「CodeBuild」サービスを選択し、「プロジェクトの作成」ボタンを押下します。

CodeBuildの主な設定項目は以下の通りです。

上記に従って入力した後、「ビルドプロジェクトを作成する」ボタンを押下してください。なお、各項目の設定が必須かどうかはAWS公式サイトの「CodeBuildでビルドプロジェクトを作成する」に掲載されている表を参考にしてください。

早速ビルドの実行と行きたいところですが、その前にビルド用のコンテナイメージがAWS Systems Manager ParameterStoreへアクセスするための権限設定を追加で実施する必要があります。

AWS Systems Manager Parameter Storeへのアクセス権限の付与

前回設定したAWS Systems Manager Parameter Storeで定義したデータを参照するには、CodeBuildの実行ロールにもアクセス権限を付与しておく必要があります（付与していない場合、実行エラーになります）。前節で作成されるサービスロールに、Systems Managerのアクセス権限を割り当てておきましょう。

AWSコンソールで、「IAM」サービスから「ロール」メニューを選択し、作成したポリシーに対して、以下のように「AmazonSSMFullAccess」のポリシーをアタッチしてください。

Buildの実行

アクセス権限の付与が完了したら、早速ビルドを実行してみましょう。「ビルドの開始」ボタンを押下し、buildspec.ymlに記載された各フェーズやログが出力されることを確認します。

また、buildspec.ymlに記載した通り、Mavenビルド中に実行したSonarScannerの実行結果も、以前の連載で設定していたSonarQubeServerへ送信されるようになります。Scannerの結果も合わせて確認し、QualityGateをパスしているかどうかチェックしましょう。

なお、SonarQubeServerもWebhookにより解析が完了したタイミングで、別の外部サービス(SlackやTrelloなど)へ処理完了通知することも可能です。詳細はSonarQubeの公式サイトにある「Webhooks」や「API/Webhooks」を参照してください。

WebHook設定

ビルドが正常に実行したことを確認したら、次はプルリクエストや特定のブランチに対するプッシュを契機に上記のビルド処理が実行されるよう、CodeBuildやGitHubのWebhookの設定を行います。

今回は以下のように、Git Flowをベースとしたブランチを構成し、赤い吹き出しの箇所でCodeBuildによるビルド処理が実行されるように設定するものとします。

上図に示した構成では、masterブランチをベースにdevelopブランチを作成し、developブランチから、featureブランチを作成しています。Git Flowのブランチモデルに従って、機能開発を各々featureブランチに対して行う想定とし、「feature/＊＊＊＊＊」となるブランチに対してプッシュが行われたタイミングで、ビルド／テストを実行するように設定します。

これにより、自らの開発対象であるfeatureブランチはもちろんですが、並行して行われるほかのfeatureブランチの変更についても、プルリクエスト(PullRequest:PR)されたdevelopブランチ経由で取り込んで、ビルド／テストが問題なく実行終了するかどうかを確認しながら開発を進めることができるようになります。なお、developブランチに対するPRによるビルド処理は、次回以降に解説します。

引き続き、GitHub上でブランチを作成して、ローカル端末へフェッチしていきます。住所系とメール系の機能を拡充するためのfeature/addressとfeature/emailを作成します。

ブランチ作成後は、ローカルへフェッチして、ブランチをチェックアウトし、feature/addressブランチへ切り替えましょう。以下はターミナルコマンドなどで実行する例です。

> git fetch
> git checkout -b feature/address origin/feature/address

続いて、住所系機能のベースモジュールを追加で実装しましょう。コミットしてプッシュする前に、CodeBuildで以下の通り、「feature/xxxxxxブランチにプッシュが行われた場合、ビルドを実行する設定」を行います。

それにはまず「CodeBuild」サービスから、「ビルドプロジェクト」メニューを選択し、前節で作成したプロジェクトを選択します。開かれた画面で「ビルドの詳細」タブにある「プライマリソースのウェブフックイベント」の「編集」ボタンを押下します。

「送信元」の変更はしませんが、プライマリソースのウェブフックイベントを以下の通り設定します。

• 「コードの変更がこのレポジトリにプッシュされるたびに再構築する」にチェック
• 「イベントタイプ」には「プッシュ」を設定
• 「これらの条件でビルドを開始する」において、「HEAD_REF」オプションに、正規表現「^refs/heads/feature/.*」を設定

上記の手順は、Backend、BFFなどCodeBuildを作成しているプロダクト単位に設定を行います。なお、設定の詳細については、AWS公式サイトの「CodeBuildのGitHubプルリクエストとウェブフックフィルタのサンプル」も適宜参照してください。

設定完了後、GitHubのfeature/addressブランチに対してプッシュした後、CodeBuildが実行されることを確認します。

マイクロサービスにおける継続的インテグレーションのまとめ

以上、ここまでの連載で、ECSコンテナ、RDSを使ったSonarQubeServerによる静的チェック環境の構築から、SpringBootを使ったマイクロサービスにおける各種テストコードの実装、GitHubへプッシュされたソースコードに対するCodeBuildを使ったビルド／テスト、SonarScannerによる静的チェック結果の可視化といった一連の継続的インテグレーション自動化の仕組みを解説してきました。

今回は触れていませんが、より上位のオプションとして、SonarQubeServer Developer Editionを使えば、静的チェックの結果をレビューコメントとしてGitHubへ反映することも可能です(なお、ComunityEditionでもGitへ連携するプラグインはありますが、現時点で既に非推奨となっているため、本連載では除外しています)。

SonarQubeServerではALB、ECS、RDSを使用して環境構築することにより、自動バックアップなどの保守性や耐障害性も高まります。また、クラウドをベースとしたCodeBuildでマシンリソースを気にすることなく、静的解析、ビルド／テスト実行を自動化し、迅速に問題検出しながら、複数人での開発をスピーティかつ効率的に進めていくことができます。 マイクロサービスアーキテクチャをベースとしたアプリケーション開発では、そのアジリティを高めるために、こうしたクラウドの利点をフル活用した、継続的インテグレーションの自動化環境が求められます。

ただし、今回、SpringBootをベースとしたWebアプリケーションで実装したSeleiumベースのE2Eテストは、バックエンドのマイクロサービスが起動している必要があるため、ビルド時には実行しないように設定しています。本来であれば、E2Eテストを含め、以下のようなプロセスでプロダクション環境へのリリースを検討します。

1. バックエンドのマイクロサービスのコンテナイメージのビルド、DockerHubへのプッシュ
2. マイクロサービスコンテナイメージをプロダクションとほぼ同等のステージング環境へデプロイ
3. Webアプリケーション(BFF)のE2Eテストとして、Seleniumテストコード実行
4. Webアプリケーション(BFF)のコンテナイメージのビルド、DockerHubへのプッシュ
5. Webアプリケーション(BFF)のステージング環境へデプロイ
6. パフォーマンステストやセキュリティテスト、受入などのその他テスト後の管理者によるリリース承認
7. ステージング環境でテスト済みのコンテナイメージをリリース用にタグ付け、DockerHubへのプッシュ
8. プロダクション環境へリリース

次回以降では、AWS CodePipelineを使って、上記をパイプライン的に自動化する仕組みを構築／解説していきます。