CodePipeline を使った Gitブランチ運用をまとめてみた

はじめに

おはようございます、もきゅりんです。

CodePipeline は使いたいのだけど、どんなデプロイフローにするか迷ってるといったことを聞くことがあります。

本稿では、CI/CDツールを CircleCI でも GitHub Actions でもなく、CodePipeline を前提として、そして代表的と思われる Git フローでどのように考えるかをまとめてみました。

諸事情と背景があって、基本的には AWSのサービス限定で CI/CDを利用したいというケースはよくあると思います。そういった状況に限定して、かつ、よくある環境セット、一般的なステージを利用した CodePipelineの CI/CDを想定しています。

とりあえず検討してみる材料にでもなれたら幸いです。

なお、どのタイプの Gitブランチフローが一番使いやすいとかそういう話はしません (できません)。

想定とする方

• CodePipeline を使ってどのようにデプロイフローを考えれば良いか参考が欲しい方

CodePipeline について

そもそも CodePipeline ってどんなだっけ？という方へ。

導入として、 Codeシリーズで始めるはじめてのCI/CD (#higobashiaws で登壇しました) | DevelopersIO は具体例を使っていて図も多く、CodePipeline およびいわゆる Codeシリーズの概要について分かりやすい資料だと思います。

詳細は、CodePipeline の概念 を参照頂ければと思いますが、CodePipeline のイメージとしては、下図のように各分離されたステージにおいて実行されるアクションを連結していくパイプラインです。各ステージは、連続または並列のアクションで構成されます。

有効なアクションタイプとアクションを実行するアクションプロバイダは下表のようになります。カスタムアクションを作成して利用することもできます。アクションも、順次または並行して実行できます。

詳細は CodePipeline pipeline structure reference - AWS CodePipeline を参照下さい。

Action Category	Action Providers
Source	Amazon S3, Amazon ECR, CodeCommit, CodeStarSourceConnection
Build	CodeBuild, Custom CloudBees, Custom Jenkins, Custom TeamCity
Test	CodeBuild, AWS Device Farm, Custom Jenkins, ThirdParty GhostInspector, etc
Deploy	Amazon S3, AWS CloudFormation, CodeDeploy, Amazon ECS, Amazon ECS (Blue/Green), Elastic Beanstalk, etc
Approval	Manual
Invoke	AWS Lambda, AWS Step Functions

CodePipeline の簡単な説明は以上です。

デプロイフローで検討する点

さて、デプロイフローを決めていく上で検討する点は以下などになるかと思います。

検討すること	考慮点	与える影響
開発規模および人数 (通常、規模と人数は比例する)	メンバーの Git スキルレベルおよびフォロー体制	規模や人数が増えればより厳密なフローになっていく
開発文化、スタイル	デプロイ(本番リリース)の頻度が高いかどうか	頻度が高いほどシンプルなフローが望ましくなる
必要な環境がなにか (本番, ステージング, 開発, レビューなど)	クロスAWSアカウントか同一アカウントか	環境が増えれば、GitHub Flow の場合、カスタマイズを要する, クロスアカウントの場合、GitHubリポジトリの方が楽
どんなステージを設ける必要があるか	CDだけでも十分か、手動承認フローは必要か	手動承認はどこで挟むか、何をもって承認できる運用にするか など
どのタイミングでどの環境にどんなデプロイをしたいのか	Blue / Green を実行するかどうか、どう実行するのか	ロールバックの手順は把握できているか など

条件

• Git フローの種類を、 git-flow, GitHub Flow, GitLab Flow, GitFeatureFlow の4つの選択肢とする
• ソースとなるバージョン管理ツールは CodeCommit, GitHub とする
• 環境は本番(prod)、ステージング(std)、開発(dev) の環境を持つ
• ブランチでデプロイ環境を分ける
• 承認ステージの有無を検討する

環境に過不足がある場合は、適宜増減して考えて頂ければと思います。

それぞれがどのようなフローになっているのか不明な方は、図を眺めて頂ければ何となく分かるかと思います。

git-flow

ブランチ	デプロイ環境	タイミング	承認ステージ
main	prod	release, hotfixes からのマージ	有
release	std	dev からのマージ	基本的に有
develop	dev	feature からのマージ	無

• A successful Git branching model » nvie.com

Environment branches with GitLab flow

ブランチ	デプロイ環境	タイミング	承認ステージ
production	prod	pre-production からのマージ	有
pre-production	std	main からのマージ	基本的に有
main	dev	feature, hotfixes からのマージ	無

• Introduction to GitLab Flow | GitLab

GitFeatureFlow

ブランチ	デプロイ環境	タイミング	承認ステージ
main	prod	feature, hotfixesからのマージ	有
test-env	std	feature, hotfixesからのマージ	基本的に有
dev-env	dev	feature, hotfixesからのマージ	無

• 新たなgitのブランチモデル「Git Feature Flow」！Git Flow,Git Hub Flow,Git Lab Flowを超…

GitHub Flow

ブランチ	デプロイ環境	タイミング	承認ステージ
main	prod	topics からのマージ	基本的に無
topics	dev	topics のプッシュ	無

• GitHub Flow – Scott Chacon
• GitHub Flow (Japanese translation)

いろいろと眺めていると、 最もシンプルな GitHub Flow から 最も複雑な git-flow の間で各開発環境で工夫を組み込んでいるようなイメージです。

例えば、 プロダクトのリリースとGitブランチ運用を考えてみた | DevelopersIO などは GitHub Flowをベースにアレンジしていて参考になります。ただし、こちらの運用では CircleCI を使って、CodePipeline で利用できないタグプッシュを利用しています。

考慮する点と上図フローをイメージしてみて、どんなブランチ運用、CI/CD が良さそうか決まりそうでしょうか。

構築について

それぞれの環境は別のAWSアカウントになることが多いと思います。

単純化された構成イメージは下記のようになります。

• 環境ごとに別AWSアカウント
• 本番環境には手動承認ステージを挟む
• ソースは1つでブランチと対でパイプラインが環境ごとに分かれている

それらの構築例は、下記ブログが参考になります。

• CodePipelineでアカウントをまたいだパイプラインを作成してみる | DevelopersIO

• 別のAWSアカウントにあるCodeCommit RepositoryをソースとするCodePipelineをCloudFormationで構築してみた | DevelopersIO

CodeCommit がソースではなく、GitHub リポジトリをソースに使った構成と構築テンプレートは GitHub/CodeBuild/CodePipelineを利用してCloudFormationのCI/CDパイプラインを構築する | DevelopersIO があります。

別AWSアカウントにある CodeCommit リポジトリを参照する必要性がないため、 複数アカウントへのデプロイの場合、GitHub リポジトリを利用する方がシンプルな構築にできます。

また、あなたの組織に最適なECSデプロイ手法の考察 | DevelopersIO で紹介されているように、ECS において上記のようにブランチごとに対となるパイプラインのデプロイではなく、テスト済みイメージを使い回すアプローチもあります。

探せば何か大体出てくる、、弊社ブログ。

最後に

本稿について、社内で何か誤解や間違いなどあれば指摘おくれよ、と意見をヒアリングする流れから逸れたのですが、「どれにしようか、どれが良いかなんて悩む前に、とりあえずどれでもいいから雑にブランチ運用して違和感があったら変更、追加、修正してけばいいよね」という意見は強く共感できました。

これが正解！というものがあるわけではないと思うので、やりながら、こねて、チームにとって合う、気持ちの良いかたちに整形していくのが宜しいのかなと感じました。

以上です。

どなたかのお役に立てば幸いです。