はじめまして。株式会社adingoのこんどう(@_zoo)と申します。
今年の4月から新しいチームに配属され、チームのバージョン管理やリリースプロセスの整備をやっています。
今回の記事ではリリースプロセスの課題解決について、チームで取り組んだ時に出てきたGitブランチの活用方法についてご紹介させていただきます。
今回の記事ではリリースプロセスの課題解決について、チームで取り組んだ時に出てきたGitブランチの活用方法についてご紹介させていただきます。
* 広告サービスの事例
まず、簡略ですが環境毎のサーバ構成をご紹介します。
DBやその他諸々のサーバも省略し、Webサーバとビルドサーバのみ記載しています。
システム的な構成の紹介はざっくりこれだけにしておきます。
システム的な構成の紹介はざっくりこれだけにしておきます。
システム構成図ではサーバ台数は一台ですがサーバが数十台に増えた時のことも考えました。
1台2台のうちはいいけれど、台数が増えてくると各サーバの状態を確認という声もありました。
数十台のサーバを運用している方からの意見だったので、かなり実感がこもっていました。
それなら、下の図のようなものが有ればいいよね、というお話になりました。
どこかで見たような図の気がします。お気づきの方もいるかもしれませんが、GitHubのNetwork図にちょっと似ています。(手書きで汚いのはご容赦を)
GitHubだと、どのブランチがどのコミットを示しているかNetwork図で確認できます。
たとえば、各サーバの状態を示すブランチがあれば、下の図のようにNetwork図を見れば一目でサーバの状態がわかります。
1台2台のうちはいいけれど、台数が増えてくると各サーバの状態を確認という声もありました。
数十台のサーバを運用している方からの意見だったので、かなり実感がこもっていました。
それなら、下の図のようなものが有ればいいよね、というお話になりました。
どこかで見たような図の気がします。お気づきの方もいるかもしれませんが、GitHubのNetwork図にちょっと似ています。(手書きで汚いのはご容赦を)
GitHubだと、どのブランチがどのコミットを示しているかNetwork図で確認できます。
たとえば、各サーバの状態を示すブランチがあれば、下の図のようにNetwork図を見れば一目でサーバの状態がわかります。
これは見やすい!ということで、サーバの状態を指し示すブランチの作成をすることなりました。
チームで色々と議論した結果として、運用するブランチは2種類、常にあるブランチと必要になったら作成するブランチ、という形になりました。
チームで色々と議論した結果として、運用するブランチは2種類、常にあるブランチと必要になったら作成するブランチ、という形になりました。
常に存在するブランチ
- master
- dev
- web-dev
- pre
- web-pre
- production
- web
必要になったら作成するブランチ
- t12345_rename_infotitle
気づいた方もいると思いますが、常に存在するブランチがやたらと多いです。
まずはこのやたらと多いブランチのそれぞれの役割を説明します。
- masterブランチ
- devブランチ
開発環境にてビルド・デプロイ・テストが終了している状態を指し示すブランチ。
- web-devブランチ
開発機の状態を指し示すブランチ。
- preブランチ
- web-preブランチ
- productionブランチ
- webブランチ
- tXXXXXブランチ
Redmineの作業チケットと紐づけられたチケットブランチ。
次に、これらのブランチの取り扱い方です。
実のところ開発者が直接コミットを行うのは、masterブランチとチケットブランチのみです。
他のブランチはどうやってコミットを取り込んでいるかというと、たとえば開発環境への取り込みは下のような流れになっています。
本番機の反映までは、下のような流れです。基本は同じことの繰り返しです。
実のところ開発者が直接コミットを行うのは、masterブランチとチケットブランチのみです。
他のブランチはどうやってコミットを取り込んでいるかというと、たとえば開発環境への取り込みは下のような流れになっています。
本番機の反映までは、下のような流れです。基本は同じことの繰り返しです。
- リリースする変更をmasterにコミット&push
- 開発環境
- web-devブランチにmasterの変更を取り込み(git reset --hard masterの最新コミット)
- 開発機(web-dev)にデプロイ
- 開発機でテスト(zombie.js)
- devブランチにmasterの変更を取り込み(git reset --hard masterの最新コミット)
- プレ環境
- web-preブランチにdevブランチを取り込み(reset origin/dev --hard)
- プレ機(web-pre)にデプロイ
- プレ機でテスト(zombie.js)
- preブランチにdevブランチを取り込み(reset origin/dev --hard)
- 本番環境
- webブランチにpreブランチを取り込み(reset origin/pre --hard)
- 本番機(web)にデプロイ
- 本番機でテスト(zombie.js)
- productionブランチにpreブランチを取り込み(reset origin/pre --hard)
補足すると、最初に話した各サーバのブランチとは別に、各環境でテストが終了したコミットを取り込みブランチを作成することになりました。
これはサーバが複数台あった場合に、プレには開発でテストされたものしか反映されない、本番にはプレでテストされたものしか反映されない、といった仕組みを実現するためにできたものです。結論をいうと、各サーバの状態がNetwork図を見れば一目でわかるようになりました。
色もついているし、見やすい、サーバに入ってgit statusとか打たなくていい!
ということで、Gitのブランチによるサーバ管理について紹介させていただきました。