はじめに
この記事はLIGTHzアドベントカレンダー 2021の8日目の記事です。
この記事では、小〜中規模のプロダクトを想定したCI/CD戦略について、自分の考えをまとめたいと思います。
前提条件
開発チームの人数： 5人程度
プロダクト規模： 小〜中規模
利用サービス
- Git: Azure Repos
- CI/CD: Azure Pipelines
- Hosting: Azure App Service
ブランチ戦略
CI/CDパイプライン構築を考える上で、「ブランチ戦略をどうするか」を考える必要があります。
- Git-flow
- GitHub-flow
- GitLab-flow
等いくつかあります。
各ブランチの戦略についてはこちらの記事でまとめてくださってますので割愛します。
個人的には、
- Gitに慣れていないメンバがいる
- デプロイの頻度が高い
といった場合はシンプルなGitHub-flowを使うとよいのではないかと思います。
CI/CD戦略
CI(継続的インテグレーション)
LintやUnitテスト、BuildなどはPushされたタイミングで毎回実行すると良いと思います。
CIジョブがキューに溜まってしまう場合には、CIの各処理の速度改善と併せて、並列ジョブ数を増やすことを検討をすると良いと思います。
CD(継続的デリバリー)
デプロイ対象環境については
- 検証環境：新機能等の検証を行う環境
- ステージング環境：本番と同じ構成でリリース前の最終確認を行う環境
- 本番環境：サービス稼働環境
の3環境を想定。
3環境に対するGitHub-flowでのCD戦略は以下の表の通り
| デプロイ環境 | デプロイタイミング |
|---|---|
| 検証 | main branchへマージ |
| ステージング | main branchのコミットにtagが打たれた(*1) |
| 本番 | 手動での承認(*2) |
*1 tagをリリースポイントとして扱う
*2 Azurepipelineでのapprovals and checks機能を用いることを想定。承認者はステージング環境で最終動作確認したQA担当等を想定
app serviceでのBlue-Green Deployment
app serviceでのホスティングの場合、ステージング・本番の各デプロイスロットを用意し、スロットをスワップすることでBlue-Green Deploymentを実現できます。
詳しくはこちらの記事でまとめてくださっています。
(Blue-Green Deploymentって何ぞや？という方はこちらの記事が参考になります)
本番へのデプロイ=ステージングスロットとのスワップ、といった感じです。
スワップを用いることで
- ダウンタイムを短くできる
- ロールバックが容易
といったメリットがあります。
おわりに
今回はCI/CDの戦略について書きました。
これからもDevOpsエンジニアとして自動化を推進し、チームの開発スピード向上とシステムの安定稼働に貢献できたらと思います。