りなGitHubを利用したCI/CDってなに?
全体像を教えてほしい!
昨今の開発現場ではよく使われるCI/CDの仕組み。
でもどうやって設定や構築をしていけばいいのかわからない、、、
と困っている人もいるのではないでしょうか?
そこで今回は、AWSエンジニア歴4年の著者が、GitHubとAWSを連携させたCI/CD環境の構築について体系立てて解説していきます。
- GitHubとAWSを連携させたCI/CD環境の構築の概要
- CI/CD環境の構築手順
- AWSリソースの追加手順
この記事を読み終わったころには、CI/CD環境の構築への理解が深まっているはずです。


なおと
AWSフリーランスエンジニア
当ブログ「なおナビ」運営者の、なおとです。
私はこんな人です👇
- IT完全未経験からAWSエンジニアに転職
- AWSエンジニアに転職して年収400万円アップ
- フリーランスとして独立(2025.11~)
このブログでは、AWSエンジニアやフリーランスを目指す「あなた」の背中を押す情報を発信しています💡
全体像
構成図
今回の構成では、Codeシリーズを利用したCI/CD環境の構築を行います。
リソースのデプロイはCloudFormationを利用します。


コードの構成
コードは下記に置いてありますので参考にしてください。
https://github.com/naoto-aws/aws-github-cicd-pipeline-public
ディレクトリ構成
ディレクトリは以下の構成で作っています。
※VPCとSubnetは同じテンプレート内に書くことが多いですが、今回は検証しやすくするためにあえて分けています。
aws-github-cicd-pipeline/
├── cloudformation/
│ ├── cicd-templates/ # CI/CD パイプラインの設定
│ │ ├── codebuild.yaml # ビルド・デプロイ設定
│ │ ├── codepipeline.yaml # パイプラインの流れ定義
│ │ ├── buildspec.yaml # ビルド実行スクリプト ★重要
│ │ └── root-stack.yaml # CI/CD全体の統合テンプレート
│ ├── templates/ # アプリケーション本体のテンプレート
│ │ ├── vpc.yaml # VPCのテンプレート
│ │ ├── subnet.yaml # subnetのテンプレート
│ │ └── root-stack.yaml # デプロイされるアプリ設定
│ └── parameters/ # パラメータファイル(環境ごと)
│ ├── dev/
│ │ └── parameter-dev.json
│ └── prd/
│ └── parameter-prd.json
└── README.md
ポイントは以下です。
- CI/CD環境のPipelineを構築するコードは、cicd-templatesフォルダ配下で管理
- AWSリソースを構築するコードは、templatesフォルダ配下で管理
- 各フォルダごとにroot-stack.yamlから各.yamlファイルを呼び出す構成
- 環境ごとに変わるパラメータはparametersフォルダで管理
前提
以下については本記事では解説していません。
ご了承ください。
- GitHubの利用方法
- VScodeの利用方法
- CloudShellの利用方法
- ソースコードの詳細な解説
事前準備
この章の対象範囲は下記になります。


①GitHubとの接続
GitHubとAWSをつなぐために、デベロッパー用ツールからGitHubとの接続を行います。
参考にした記事はこちらです。
以下のようにARNが発行されればOKです!
(このARNはコード内で利用します。)


②S3の作成
S3は事前に手動で作成しておきます。
S3の作成をPipelineの中に組み込んでもよいのですが、今回は組み込んでいません。
S3の用途は以下の通りです。
- Pipeline構築用のテンプレートの格納
- PackageFileの格納
こちらで作成したS3バケット名もコード内で利用します。
リソース構築用のPipelineの作成
自動構築を行うためのPipelineは、手動での作成となります。
「卵が先か、鶏が先か」の話になりますが、自動構築する仕組みを作るために、最初は手動での環境構築が必要です。
この章での対象範囲は以下になります。


CloudShellにコードを配置する
ローカルにある、cloudformationフォルダをzip化してCloudShellにアップロードし、解凍します。
~ $ ll
total 16
drwxrwxrwx. 5 cloudshell-user cloudshell-user 4096 Nov 16 12:03 cloudformation
-rw-r--r--. 1 cloudshell-user cloudshell-user 9518 Nov 16 21:51 cloudformation.zip
CloudShellからdeployする
コマンド①
CI/CDのPipelineを作るroot-stack.yamlが格納されているディレクトリへ移動
cd cloudformation/cicd-templates/
実行すると⇩の様になると思います。
~ $ cd cloudformation/cicd-templates/
cicd-templates $
cicd-templates $
cicd-templates $ ll
total 32
-rw-rw-rw-. 1 cloudshell-user cloudshell-user 1166 Nov 16 21:49 buildspec.yaml
-rw-rw-rw-. 1 cloudshell-user cloudshell-user 1859 Nov 16 21:25 codebuild.yaml
-rw-rw-rw-. 1 cloudshell-user cloudshell-user 4560 Nov 15 23:55 iam-roles.yaml
-rw-rw-rw-. 1 cloudshell-user cloudshell-user 5079 Nov 16 21:25 pipeline.yaml
-rw-rw-rw-. 1 cloudshell-user cloudshell-user 2708 Nov 16 11:49 root-stack.yaml
コマンド②
packageを作成するコマンド
aws cloudformation package \
--template-file root-stack.yaml \
--s3-bucket <S3バケット名> \
--output-template-file cicd-packaged.yaml
これは何をやっているかというと
root-stack.yamlを読み込んで、deploy用のファイルを作成しています。
- ./codebuild.yamlなど、ローカルのパスで記述している個所をS3のURLに変換してくれます。
- URLを変換したファイルをcicd-packaged.yamlとして、同じディレクトリ内に作成してくれます。
元のroot-stack.yamlとパッケージコマンドで作成したcicd-packaged.yamlを比較してみましょう。


ローカルのファイルパスがS3のURLに変換されているのがわかると思います。
コマンド③
package化したファイルをdeploy
aws cloudformation deploy \
--template-file cicd-packaged.yaml \
--stack-name agcp-dev-cicd-deployment-stack \
--parameter-overrides \
ProjectName=agcp \
EnvName=dev \
GitHubConnectionArn="GitHubとの接続ARN" \
GitHubRepo="ご自身のリポジトリ名" \
GitHubBranch="develop" \
ArtifactBucket="<S3バケット名>" \
ArtifactBucketArn="<S3バケットのARN>" \
--capabilities CAPABILITY_NAMED_IAM
これでPipelineが作成されます。
完成
完成イメージです。


ここまできたら、CI/CD環境の構築は終わりです。
このあとは、ディレクトリ構成で説明したtemplatesディレクトリにあるファイルを更新していくフェーズに入ります!
リソース構築
ここから、リソースの構築に入っていきます。
この章での解説範囲は以下の通りです。


コードの追加
CI/CDの仕組みが出来上がった後は、構築したいリソースをtemplates/配下に追加していきます。
aws-github-cicd-pipeline/
├── cloudformation/
│ ├── cicd-templates/ # CI/CD パイプラインの設定
│ │ ├── codebuild.yaml # ビルド・デプロイ設定
│ │ ├── codepipeline.yaml # パイプラインの流れ定義
│ │ ├── buildspec.yaml # ビルド実行スクリプト ★重要
│ │ └── root-stack.yaml # CI/CD全体の統合テンプレート
│ ├── templates/ # アプリケーション本体のテンプレート
│ │ ├── vpc.yaml # VPCのテンプレート
│ │ ├── subnet.yaml # Subnetのテンプレート
│ │ └── root-stack.yaml # デプロイされるアプリ設定
│ └── parameters/ # パラメータファイル(環境ごと)
│ ├── dev/
│ │ └── parameter-dev.json
│ └── prd/
│ └── parameter-prd.json
└── README.md
構成としては、root-stack.yamlが各AWSリソースのテンプレートファイルを呼び出す構成になっています。
よって、リソースを追加するたびにroot-stack.yamlへの追加も忘れないようにしないといけません。
Pipelineが動き出す
コードができたら、指定のブランチ(今回のコードではdevelop)へPushします。
そうすると、PipelineがGitHubからソースコードを取得する処理が始まります。


①,SourceでGitHubからソースを取得
⇩
②,Build-and-Packageで①で取得したソースコードをもとに、リソース構築用ファイルの作成とparameterファイルの作成
⇩
③,後ろ3つのステージで、②で作成したファイルをもとにリソースを構築
ざっくり、こういった流れになっています。
リソースの構築確認
あとはエラーが出なければリソースが自動的に構築されます。
最終的には、CloudFormationでリソースを構築しています。


実際に環境を確認してみると⇩
構築されていることがわかります。


以上で構築編も完了です!
まとめ
今回はGitHubとAWSを連携させたCI/CD環境の構築について解説しました。
概要は掴めましたでしょうか?
ソースコードの解説は今回は割愛したので、もしご要望が多ければ追記したいなーと思っています💡
お気軽にコメントやお問い合わせください。
CI/CD環境を構築するメリット
CI/CDの1番の魅力は、
複数環境に同じ構成のシステムを再現性高く構築できることだと思います。
構築に人の手が加わらないので、ヒューマンエラーを減らすこともできます。
そして、2025年現在ではCI/CD環境を取り入れているプロジェクトが数多くあります。
CI/CD環境を構築できるようにしておくと、仕事の幅が広がるというメリットもあると思います!
感想:最初はとっつきにくいけど仕組みが分かれば楽しい
正直、最初はチンプンカンプンでした(笑)
各サービスの名前は知っていたものの、具体的にどんな処理が走るのか、どうやって連携させるのか。
など、1つ1つ調べながら格闘しました。
ただ、1回仕組みが分かれば楽しくなってくるので、ぜひチャレンジしてみてください!
本サイト「なおナビ」では、AWSエンジニアにまつわる情報を発信しています。
- AWSエンジニアについて知りたい!
- AWSエンジニアになる方法が知りたい!
- ぶっちゃけAWSエンジニアって稼げるの?
こんな疑問を持っている方はぜひ他の記事も読んで、AWSエンジニアについて知ってもらえたら嬉しいです。
最後まで読んでいただきありがとうございました!
実はこの記事は、なおナビで初の技術ブログでした(パチパチパチ)
普段はこれからエンジニアになりたい、エンジニアのキャリアに困っている人向けに、私の今までのキャリアで得た経験や知識をシェアするような記事を書いています。
ただ、技術者たるもの技術ブログも書かないといけない(そんなことない)と思い、今回執筆に至りました。
技術ブログが他にある中で本記事を読んでいただいたことに感謝申し上げます。
疑問に思ったことや分かりづらいとこがあれば気軽に X(@naoto_naonavi)かお問い合わせフォームまでご連絡ください!



コメント