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

大文字小文字、ハイフン入る入らないがまちまちで、どれが真なのかよくわからない。
2021.03.26

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

はじめに

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

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

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

詳細は 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 からのマージ

git-flow

Environment branches with GitLab flow

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

gitlab-flow

GitFeatureFlow

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

gitfeature-flow

GitHub Flow

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

github-flow

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

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

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

構築について

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

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

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

pipeline_image

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

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

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

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

ecr_source

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

最後に

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

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

以上です。

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