CodeDeployによるバージョン管理とステージング

渡辺修司

2015.12.02

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

渡辺です。

先日よりAWS CodeDeployが東京リージョンで利用できるようになりました。ぼちぼちプロジェクトで活用しているチームもあるかと思います。今回のエントリーでは、そんなCodeDeployでどのようにアプリケーションのバージョンとステージングを管理するかについて整理したいと思います。細かいCodeDeployの操作手順は、他のエントリーを参照してください。

CodeDeployの構造

CodeDeployを理解するには、アプリケーション・デプロイグループ・リビジョンの３つの要素を正しく理解する必要があります。これらは入れ子構造になっています。アプリケーションが複数のデプロイメントグループを持ち、デプロイグループが複数のリビジョンを持つ構造です。

この構造を、本番環境と検証環境のあるアプリケーションに適用すると次のようなイメージとなります。

アプリケーション

CodeDeployのアプリケーションは、最も大きな単位で、アプリケーション自体が何か特別な意味を持つワケではありません。複数のアプリケーション（システム）があるのであれば、複数のアプリケーションという程度の感覚でOKです。

デプロイグループ

CodeDeployのデプロイグループは、デプロイ対象となるEC2インスタンスなどをグルーピングした単位です。ユースケースとしては、APIグループ・Batchグループのようにサブシステム毎に作成するか、本番環境と検証環境のようにステージ毎にグループを作成するか、その両方かという形になります。デプロイグループは、例えば、「Name=Webとタグ付けされたEC2インスタンス」といった指定になります。同一リージョンであれば、VPCをまたいでグループを構成できることできます。

リビジョン

CodeDeployのリビジョンとは、アプリケーションのリリース単位です。つまり、リビジョンは、デプロイするコンテンツなどをパッケージングされたファイル群となります。 リビジョンは環境（デプロイグループ）毎にデプロイ単位で作成します。

このリビジョンを作成する部分がCodeDeployのキモとなります。

リビジョン作成のポイント

リビジョンは、アプリケーションでデプロイするソースファイル・バイナリファイル・設定ファイル、さらにデプロイ時に実行するフックスクリプトなどで構成されます。これらはパッケージングされ、S3に登録するかGitHubに登録しなければなりません（今回はS3）。リビジョンは各デプロイグループのリビジョン毎に作成します。

ステージングとリビジョン

デプロイにおける一番の課題は、環境（ステージ＝デプロイグループ）毎のパッケージの差異をどう扱うかです。例えば、本番環境と検証環境では、接続先データベース・ログレベル・ドメイン名などが異なるでしょう。このような差異は、リビジョンを作成する時に吸収します。

リビジョンを考慮したデプロイ

デプロイグループ毎の差異を考慮したリビジョンは、ビルドサーバなどを利用してビルドすることをオススメします。ビルドサーバでは、GitなどのSCMからソースコードを取得し、環境毎の設定を行った上で、リビジョン（パッケージ）をビルドします。ビルドが成功したならば、リビジョンをS3にアップロードし、CodeDeployのリビジョンとして登録してください。これらの手順は、利用するプログラミング言語に適したビルドツールを使うなど、自動化することが必要です。自動化が行われるのであれば、ローカル環境で実行してもよいでしょう。

CIによるビルド

ビルドサーバは、JenkinsのようなCIサーバとして構築するのも良い選択です。ただし、ユニットテストやJavaのコンパイルといった複雑な手順がないのであれば、CIサーバは過剰かもしれません。

CodePipeline

ビルドサーバで行っている部分をサポートするのがAWS CodePipelineです（2015年12月1日時点では東京リージョンでは利用できません）。 CodePipelineを導入する事で、さらに自動化が進みますが、複雑なビルド手順がないのであれば、スクリプトやビルドツールでビルドしても良いでしょう。