AWS環境でのCI/CDパイプライン構築のベストプラクティス

CI/CDとは

CI/CDとは、ソフトウェアの開発からリリースまでのプロセスを効率化するための手法や仕組みのことを指しています。CIは「継続的インテグレーション（Continuous Integration）」、CDは「継続的デプロイ（Continuous Deployment）」の略です。これらを組み合わせることで、品質を保ちながら迅速にシステムを更新できる仕組みを構築します。

CIとは

CI（継続的インテグレーション）は、開発者が頻繁にコードを開発・共有し、自動的にテストを行うプロセスです。これにより、システム開発におけるエラーを早期に発見し、修正することが可能です。CIを導入することで、チーム全体でコードの品質を維持しやすくなり、開発効率が向上します。

CDとは

CD（継続的デプロイ）は、CIで統合されたコードを、本番環境に自動的または手動でリリースするプロセスです。継続的デリバリーでは、本番リリースを自動化する準備を整え、継続的デプロイでは、実際にリリースまで自動で実行します。これにより、頻繁に小さな変更を反映でき、リリースサイクルが短縮されます。

CI/CDとは

CIとCDを組み合わせたCI/CDは、開発からデプロイまでの極力自動化を行う仕組みのことです。これにより、システムへの新機能追加やパッチ適用といったリリース作業が効率化され、エラーの発生を抑えつつ、短期間で更新を実施できます。

AWS CODEシリーズを活用して柔軟な開発環境を実現するスタイルズのDevOps(CI/CD)導入支援サービスはこちら→

AWSにおけるCI/CD導入のメリット

AWSを活用したCI/CDの導入には、複数のメリットがあります。まず、リリース作業の自動化により、開発チームは煩雑な手作業から解放され、より迅速に品質の高い成果物をリリースできます。たとえば、手動でデプロイを行う場合、コマンドやコードの適用先の間違いといったヒューマンエラーのリスクが高まり、リリースのたびに問題が発生することがあります。近年では、2024年7月にセキュリティソフトウェアに欠陥がある状態でアップデートが行われ、世界的にWindowsサーバーが停止するといった障害も発生しました。しかし、CI/CDの自動化パイプラインを使用することで、変更を本番環境に安全にリリースすることができます。

もしCI/CDを導入しない場合、コードの修正やデプロイが手動になるため、ミスを減らすために更新頻度が低下し、ユーザーからのフィードバックや法令への変更への対応を迅速に実施できないリスクがあります。また、変更の規模が大きくなり、リリース作業が複雑化し、リスクも増加します。これに対してCI/CDを導入することで、小さな変更を頻繁に安全にリリースでき、ユーザー体験を向上させることができます。

AWSにおけるCI/CDのテクノロジースタック

AWSでは、CI/CDをサポートする複数のサービスを提供しています。これらのサービスを利用することで、開発からデプロイまでのプロセスをシームレスに構築できます。

• パイプライン…パイプラインとは、CICDを実現するフローのような仕組みと考えてください。AWS CodePipelineを使用して、リリースプロセスを自動化し、コードのビルド、テスト、デプロイをステージごとに管理します。
• リポジトリ…ソースコードの保存先です。ソースコードはAWS CodeCommitで管理され、チーム内で安全に共有できます。(*)2024年7月、AWSはCodeCommit サービスの新規利用受付を終了すると発表しました。CodeCommit の代替としては、GitHub や GitLab などの外部の Git リポジトリサービスが候補となります。
• ビルド…ビルドとは、プログラミングしたコードをサーバー上で動かせるようにすることです。AWS CodeBuildを使用して、ソースコードをビルドし、必要なアーティファクトを作成します。
• デプロイ…AWS CodeDeployを利用して、アプリケーションのデプロイを自動化します。これにより、サーバーやインスタンスへのデプロイがスムーズに行えます。
• アーティファクト…アーティファクトとは、ITの世界においてはビルドされた成果物のことです。つまりは、コードをビルドした結果、動かせるようになったプログラムのことです。AWSでは、CodeArtifactを利用して成果物を格納します。
• コードレビュー…CodeGuruを使用して、AIによるコードレビュー、バグチェックを実施します。

これらのステップを組み合わせることで、AWS上で一貫したCI/CDのパイプラインを構築でき、開発プロセスの効率化と信頼性を向上させることが可能です。

AWSにおけるパイプラインのパターン整理：デプロイ

AWSにおけるCICDについて、まずはアプリケーションのデプロイに関する基本的な流れを見ていきましょう。

基本的な流れ

基本的な流れとしては、パイプラインの開始トリガーをもとに、CodeBuildやCodeDeployが起動するような形になります。アプリケーションの場合は、パイプラインの開始トリガーはCodeCommitやECRなどへソースコードがプッシュされることによりパイプラインがスタートします。

サーバー上へのアプリケーションへのデプロイ

EC2などで稼働するアプリケーションについては、CodeBuildがアプリケーションのビルドとテストを実施し、CodeDeployに引き渡してサーバーにビルドする、といった標準的なフローをたどり、パイプラインが実行されます。

コンテナのデプロイ

コンテナの場合、ビルドで作成されたアプリケーションはコンテナという形でECS等にデプロイされます。したがって、CodeBuildがDockerイメージの作成とテスト、コンテナのタスク定義の作成等を行います。

Lambdaなどのサーバーレスサービスへのデプロイ

Lambdaの場合もCodeBuildやCodeDeployを利用することは変わりませんが、Lambdaにデプロイするためには、CodeDeployで利用する『appspec.yml』というファイルを、CodeBuildで作成する必要もあります。

AWSにおけるパイプラインのパターン整理：プロビジョニング

プロビジョニングとは、サーバーやネットワークをCloudFormationやTerraformのようなサービスで構築することを言います。アプリケーションと異なり、インフラ寄りと考えるといいでしょう。基本的な流れは、パイプラインのトリガーから、Codepipelineの各ステップでCloudFormationを実行する形になります。

変更セットと承認

インフラの変更は、1歩間違えればNWの疎通が取れなくなるなど、サービスに大きな影響が出ることがあります。そのため変更セットという、インフラへの影響を事前に確認することが可能になっています。そのため、すべて自動で実行されるのではなく、Codepipelineに承認フローを設けることで、変更セットを確認し、インフラへの影響を抑えることが可能です。

EC2を含めたプロビジョニング

CloudFormationはあくまでのインフラ部分の対応となっており、EC2などのOS以上のレイヤには対応していません。そのため、EC2を含める場合は、既存のAMIを指定したり、ビルドのステップでAMIを作成したり、といった対応が必要になります。

AWS CODEシリーズを活用して柔軟な開発環境を実現するスタイルズのDevOps(CI/CD)導入支援サービスはこちら→

まとめ

AWSのCI/CDとパイプラインの導入により、開発プロセスの効率化とリリースサイクルの短縮が可能となります。デプロイやプロビジョニングも対応しており、アプリからインフレまで対応することが可能です。AWSでは、CICDの実現に向け豊富なツール群が用意されており、これらを活用することでアプリケーションの機能提供や法令対応が高速化し、ビジネス価値の向上を実現することが期待されます。導入に向けては、要件に応じて様々なパターンが考えられるため、専業のベンダーに相談するといいでしょう。