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 からのマージ | 無 |
Environment branches with GitLab flow
| ブランチ | デプロイ環境 | タイミング | 承認ステージ |
|---|---|---|---|
| production | prod | pre-production からのマージ | 有 |
| pre-production | std | main からのマージ | 基本的に有 |
| main | dev | feature, hotfixes からのマージ | 無 |
GitFeatureFlow
| ブランチ | デプロイ環境 | タイミング | 承認ステージ |
|---|---|---|---|
| main | prod | feature, hotfixesからのマージ | 有 |
| test-env | std | feature, hotfixesからのマージ | 基本的に有 |
| dev-env | dev | feature, hotfixesからのマージ | 無 |
GitHub Flow
| ブランチ | デプロイ環境 | タイミング | 承認ステージ |
|---|---|---|---|
| main | prod | topics からのマージ | 基本的に無 |
| topics | dev | topics のプッシュ | 無 |
いろいろと眺めていると、 最もシンプルな 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 において上記のようにブランチごとに対となるパイプラインのデプロイではなく、テスト済みイメージを使い回すアプローチもあります。
探せば何か大体出てくる、、弊社ブログ。
最後に
本稿について、社内で何か誤解や間違いなどあれば指摘おくれよ、と意見をヒアリングする流れから逸れたのですが、「どれにしようか、どれが良いかなんて悩む前に、とりあえずどれでもいいから雑にブランチ運用して違和感があったら変更、追加、修正してけばいいよね」という意見は強く共感できました。
これが正解！というものがあるわけではないと思うので、やりながら、こねて、チームにとって合う、気持ちの良いかたちに整形していくのが宜しいのかなと感じました。
以上です。
どなたかのお役に立てば幸いです。
