前のパートに戻る 完了して次のパートへ  

  0-6 自動テスト・自動デプロイの流れの解説

本パートでは、本教材で学ぶ自動テスト・自動デプロイの流れを説明します。

なお、本パートで説明している内容を全て覚えてから先に進む必要はありません。

各章を進めながら、徐々に内容を把握していけば充分です。

1. 自動テストの流れ


本教材での、CircleCIを用いた自動テストの流れは以下の図のようになります。

ローカルPCなどから、ブランチをGitHubへプッシュすると、CircleCIはGitHubからそのコードを取り出し(チェックアウトし)、テストを実行します(図の1, 2, 3)。

(この図ではfeatureブランチと記載していますが、それ以外の名前のブランチでもテストは実行されます)

また、GitHubで、このブランチに対するPR(プルリクエスト)が立てられていれば、そこにテストの成否が表示されます。

通常、テストに合格し、コードレビューで承認されていれば、masterブランチにマージします(図の4)。

この流れにより、一定の品質のコードだけがmasterブランチに取り込まれるようになります。

なお、masterブランチにマージされた後のコードも、CircleCIでテストが実行されます(図の5, 6)。

2. AWSの構成


本教材では、AWSに構築したサーバーに自動デプロイを行います。

自動デプロイの流れを解説する前に、AWSのサーバー構成を説明します。

以下の構成図を見てください。

EC2とRDSそれぞれ一台ずつのシンプルな構成となっています。

Laravel + Vue.jsのサンプルアプリケーションはEC2に対してデプロイします。

また、デプロイの都度、RDSのデータベースに対して、マイグレーションを行います。

デプロイ内容に、もしマイグレーションファイルの追加・更新があれば、マイグレーションによってデータベースの定義は最新化されます。

3. 自動デプロイの流れ


本教材では、自動デプロイの方法として、3種類の方法を学びます。

3.1. CircleCIだけで完結するデプロイ

先ほどの自動テストの図に「7〜11」のデプロイ処理を追加したのが、以下の図となります。

masterブランチにマージ(図の4)された後、CircleCIではテスト(図の5, 6)に加えて、デプロイ処理を開始します(図の7)。

具体的にはCircleCIからAWSのEC2にSSHでログイン(図の8)し、GitHubの最新のmasterブランチからソースコードをEC2に反映(git pull)します(図の9)。

次に、EC2上でビルド(PHPやJavaScript関連のパッケージインストールや、JavaScriptのトランスパイル等)を行います(図の10)。

最後にRDSのDBに対して、マイグレーションを実行します(図の11)。

CircleCIだけで完結する、シンプルなデプロイ方法となります。

この後に説明するデプロイ方法と比較した特徴として、

  • ビルドをサービスの稼働するEC2上で直接行っている
  • CircleCI側のIPアドレスは固定ではないため、EC2側は全てのIPアドレスからのSSH接続を許可しておかなければらない

という点が挙げられます。

3.2. CodeDeployも使ったデプロイ

以下の図は、先ほどの「CircleCIだけで完結するデプロイ」の図の「7」以降を差し替えたものとなります。

CircleCI上でビルドを行った上で、デプロイ処理を開始します(図の7)。

ビルド後のファイル群は、CircleCIによって、AWSのストレージであるS3にアップロードされます(図の8)。

次に、CircleCIからAWSのデプロイサービスであるCodeDeployにデプロイ開始を指示します(図の9)。

さらにCodeDeployは、EC2に別途インストール済みのCodeDeployエージェントにデプロイ処理を指示します(図の10)。

CodeDeployエージェントは、S3からビルド後のファイル群を取り出し、EC2にデプロイします(図の11)。

また、CodeDeployエージェントには任意の処理を実行させることができるので、これを利用し、EC2からRDSのDBに対してマイグレーションを実行します(図の12)。

先ほどの「CircleCIだけで完結するデプロイ」と比較した特徴として、

  • ビルドをあらかじめCircleCIで済ませているため、EC2上でのデプロイにかかる処理時間が短い

という点が挙げられます。

また、本教材では触れませんが、CodeDeployを使うことで

  • 複数台のEC2に対して、サービスを停止させずに順次デプロイする

といったことも可能になります。

3.3. Code4兄弟を活用したデプロイ

以下の図は、先ほどの「CodeDeployも使ったデプロイ」の図の「7」以降を差し替えたものとなります。

CircleCI上でビルドは行わず、デプロイ処理を開始します(図の7)。

CircleCIからAWSのCodeCommitに対し、最新のmasterブランチをプッシュします(図の8)。

CodeCommitとは、AWS上に存在するGitリポジトリのサービスです(AWS版のGitHubのようなものです)。

CodeCommitに最新のmasterブランチがプッシュされると、そのコードがS3にコピーされ(図の9)、これをCodeBuildが取得します(図の10)。

CodeBuildではビルドを行い(図の11)、ビルド後のファイル群をS3にコピーします(図の12)。

CodeDeployからの指示(図の13)を受けたCodeDeployエージェントは、S3からビルド後のファイル群を取り出し、EC2にデプロイします(図の14)。

また、CodeDeployエージェントには任意の処理を実行させることができるので、これを利用し、EC2からRDSのDBに対してマイグレーションを実行します(図の15)。

図の左側にあるCodePipelineは、CodeCommit, CodeBuild, CodeDeployとS3の連携や、一連のデプロイ処理のステータス管理を行います。

なお、ここに登場したCode...から始まる4サービスのことを、俗にCode4兄弟と呼ぶことがあります。

先ほどの「CodeDeployも使ったデプロイ」と比較した特徴として、

  • CodeBuildのCPU、メモリを増強することでビルドを高速化することが可能

という点が挙げられます。

4. どのデプロイ方法が良いか

本教材では3種類のデプロイ方法を解説しますが、一概にどの方法が最も優れている、とは言えません。

また、本教材で解説する方法以外にもさまざまなデプロイ方法が考えられます。

実際の開発では、デプロイ対象のWebサービスの規模や、CI/CDパイプラインの構築までに求められるスピードなども考慮し、適切なデプロイ方法を選択してもらえればと思います。

議論

0 質問

このコースの評価は?