Git flowにGitOpsを導入した事例紹介
はじめに
私たちのチームではブランチ戦略にGit flowを採用しています。
巷ではGitOpsを導入する所も増えているようで、当チームでも昨年に導入しました。
導入にあたっては、「どのブランチの更新をトリガーにして、どの環境にデプロイするのか？」「どのオペレーションを自動にして、どのオペレーションを手動承認するのか？」などをチームの状況に合わせて決める必要がありました。
今回は当チームでの運用を一例としてご紹介いたします。
Git flowとは？
伝統的なGitのブランチ戦略です。
A successful Git branching model
最近はGitHub flowなどの軽量なフローを好んで採用するチームも多いと思いますが、当チームでは各リリース毎に外部のQAやステークホルダーを絡めてみっちりとテストをするので、テスト期間が長くなりがちです。
テスト期間中も開発者にはどんどん次のリリースに向けて開発してもらいたいので、初めからreleaseについて定義されているGit flowを採用しています。
GitOpsとは？
こちらのスライドが分かりやすかったのでリンクを貼らせて頂きます。
忙しい人のためのGitOps入門 / GitOps Introduction (Short version)
k8sの文脈で語られることが多いですが、個人的に最大の発明は「CI/CDの権限分離」だと考えています。
この発明でCI（開発者）とCD（運用者）の間に明確な境界線が引かれました。これによって今まで曖昧になっていた問題が綺麗に整理されます。
余談ですが私の経験ではSPAが流行った時と近い感覚があります。SPAではFrontendとBackendに明確な境界線が生まれたことで、自然と責務が整理されて間のインターフェイスが洗練されました。その感覚に近いと感じています。
上記のことから、たとえデプロイ先がPaaSやIaaS、はたまたオンプレサーバーであっても、CI/CDの権限分離の考え方を導入することは可能だと考えていますし、実際にk8sへ移行するまではPaaSに対してGitOpsモドキと称してフローを組んでいました。
アプリケーションの実行環境
当チームの実行環境は以下の３種類に分かれています。
| 環境名 | 用途 |
|---|---|
| DEV | 開発中のアプリケーションをデプロイします。 develop、feature、bugfixブランチに対応するアプリケーションがデプロイされています。 ステークホルダーにデモ版として共有することもあります。 |
| STG | リリースバージョンをデプロイします。 release、hotfixブランチに対応するアプリケーションがデプロイされています。 リリース前のテストはこの環境で実施します。 |
| PROD | 本番サービスで稼働するアプリケーションをデプロイします。 次期リリース版を含む複数バージョンのアプリケーションがデプロイされており、代表ドメインのマッピングを変更することで瞬時にバージョンの切り替えが行えます。 |
各ブランチの更新でトリガーされる処理
全体像はこのような形です。
それぞれのブランチが更新された時に実行される処理について説明します。
feature, bugfix
featureまたはbugfixブランチの更新で、DEVにアプリケーションをデプロイします。
デプロイされたアプリケーションにはブランチ名を元にした一時的なURLを割り当てます。
develop
developブランチの更新で、DEVにアプリケーションをデプロイします。
デプロイされたアプリケーションにはDEVの代表ドメインを割り当てます。
release
releaseブランチの更新で、STGにアプリケーションをデプロイします。
DEVと同様に一時的なURLを割り当てるのと同時に、STGにおける代表ドメインの向き先をデプロイされたアプリケーションに変更します。
また、同時にPROD向けにデプロイPull Request（以後PR）と、リリースPRを作成します。
運用者がデプロイPRを承認してマージすることでPRODにアプリケーションがデプロイされ、リリースPRを承認してマージすることでPRODの代表ドメインの向き先が変更されます。
hotfix
hotfixブランチはreleaseとほぼ同じ動きをしますが、STGの代表ドメインの向き先は変更されません。
これはSTGで次のリリースのQAなどを実施している場合があるので、その時の状況に応じて手動で変更するためです。
アプリケーションの削除
ワークフローの共通処理として、アプリケーションの削除も組み込んでいます。
DEVにデプロイされた開発中のアプリケーションについては、対応するブランチが削除されると自動で削除されるようにしています。
STG、PRODにデプロイされたリリース版のアプリケーションについては、時期を見て手動削除する運用をしていますが、今後はこの部分も上手いこと自動化していきたいです。
各フェーズでのDeveloper eXperience（開発者体験）
開発着手
featureブランチを作成して開発を始めます。
修正をgit pushする度にDEVに自動デプロイされるので、好きな時にアクセスして動作を確認することができます。
ステークホルダーに動作確認を依頼するのもURLを共有するだけで可能ですし、PRをコードレビューする時もレビュワーは手元で実行する必要がなく実際の動きを確認できます。
開発終了
コードレビューが終わってPRをdevelopにマージするとDEVに自動デプロイされます。
常に開発最新版の動きを実際に触りながら確認できるので、featureブランチで作業をしていてバグのような挙動に遭遇した場合も、DEVの最新版と比較して自分のコードに問題があるのか？開発最新版に問題があるのか？の切り分けができます。
リリース準備
releaseブランチを作成するとSTGに自動デプロイされます。
STGにデプロイされたアプリケーションに対してQA、システムテスト、リグレッションテスト、パフォーマンステストを実施します。
不具合が見つかった場合は、releaseブランチを更新するだけでSTGに再デプロイされます。
リリース
releaseブランチを作成した時に自動的にPRODのデプロイとリリースのPRが作成されているので、運用者はPRを承認してマージするだけでデプロイやリリースが完了します。
おわりに
今回は当チームでの導入事例を紹介してみましたが、いかがでしたでしょうか？
皆様がよりよいエンジニアライフを満喫するための一助になれば幸いです。
Discussion