その後の俺のオレオレgit-flow〜deployment手法とgit運用

こういうふうにまとめてくださっていたのですが、自分なりの考えの補足など。

上記でも言及している、「俺のオレオレgit-flow」というエントリにも書きましたが、この運用で進めてみて結構良かったなーと思っている。その辺に関しては以下のツイートしたりした。

masterでQA通してからreleaseブランチにマージしてdeployって感じすなー。
— songmu (@songmu) 2014, 5月 30

ゲームだと画像内の文字の表記間違いとかをやらかすだけで、その事後対応でプログラマの稼働が下手すりゃ一日飛ぶので、master直deployは怖いので、並列でreleaseブランチを走らせて、そっちにマージしつつdeployしてる。
— songmu (@songmu) 2014, 5月 30

masterからreleaseへのマージはp-rにして、リリースノート的なやつを書くと良いなってのは最近思いました。
— songmu (@songmu) 2014, 5月 30

最後のリリースフローをpull requestにするっていうのは、naoyaさんのGithub時代のデプロイ戦略を見ていいなーと思ったので取り入れた。

ちなみに、Web UI上で、master -> releaseへのマージボタンを押したところで、メインブランチ(master)に対するdeleteボタンは出現しなかったのでなんとなく精神的に安心であった。

deployment手法とgit運用

僕がプロジェクトをやるときは以下の様なdeploy手法を取る。もちろんある程度スクリプト一発でできるようにしてあるのだが、中身の手順としては以下の様な感じになる。

各appで並列でgit pullをするというような話も聞くし、その方法でも良いと思うが以下の様なことが気になって、Rsyncを使っている。

deploy中(特に並列実行中)にgitサーバーが落ちたら困りそう
git gcが走ったらうざそう
本番に配置する必要がない/したくない、ファイルもある(テストファイルとかDebug用のControllerとか。もちろん配置したところで動かないようにはしてあるが)

上の手順の2の場合、何も考えずにreleaseをpullするだけという単純さが良い。

また、releaseブランチには基本的にdeployされたリビジョンしか存在しないというメリットがある。

これはロールバックをするときに非常に楽で、ミスった時にreleaseブランチの一個前のコミットをcheckoutしてRsyncしなおせば切り戻しをすぐにおこなうことができる。

deploy時にDBのスキーマ変更が行われていた場合でも、GitDDLを使ってコミットハッシュとDBのスキーマの状態を紐付けているので、任意のコミットをcheckoutしてその時点のDBスキーマに切り戻すことが可能になっている。幸いにもこのオペレーションが発生したことは無い。

ちなみに、DBのスキーマmigrationに関しては、現状の本番環境と開発環境で差異が発生している時には、ちゃんとmigrationとrollbackが出来るかどうかに関してテストを書いてCIを回すようにしている。