質問: ### 前提・実現したいこと・発生している問題 とあるWEBサービスにgitを使用して本番にデプロイする際に、git pull を使ってデプロイするとします。 例としてこれからデプロイするファイルが2つあり、A、Bとします。 ・Aのみをデプロイした場合にはWEBサービスにエラーが出ない ・Bのみをデプロイした場合にはWEBサービスにエラーが出る ・A→Bの順番でデプロイした場合にはWEBサービスにエラーが出ない ・AとBのファイルは1つのファイルとして結合することはできない ・WEBサービスは秒間リスエストが非常に多いサイト とします。 ファイルA、Bはほぼ同時にデプロイされるはずなので、そもそもファイルA,Bがどちらが先に反映されるかなど些細な問題なのですが 諸事情により1エラー足りとも、エラーを出すことが許されない状況でして、デプロイの手法について悩んでいます。 例えばgit pullを実行後、ファイルの反映がB→Aとなってしまう場合があれば、一瞬でもエラーが発生してしまう可能があります。 ### 試したこと ファイルAを先にデプロイをすればエラーが発生しないため、Aをデプロイ後、あとからファイルBをデプロイしております。 しかしあまり頭の良いやり方ではないのではと考え、何かいい方法はないかと探っておりますが思いつきません。 git pull時に反映する順番を選べるなど(comitした順番になるのか、容量なのか、タイプスタンプ、またはファイル名のソートなのかなど)の 情報があればぜひ試してみたいのですが、知りたいことの情報が出てこないため、ぜひ文献や情報、解決策、皆様のお知恵を拝借したいです。 ### 補足情報(FW/ツールのバージョンなど) 申し訳ありませんが ・ファイルのアップロード順でエラーが発生してしまうこと自体が問題、というのは今回はなしにしてください。 ・WEBサービスをメンテナンスモードにすることは許されていない状況です。 何卒、よろしくお願いいたします。
回答: この疑問はもっともで、それを対策する為にブランチという概念がGitには備わっています。 また、デグレを起こさない為のブランチ運用戦略というものがいくつも考案されています。 ブランチ運用戦略の内、有名なやり方は名前がついており、 GitFlowやGitHubFlowが有名です。 それをカスタマイズして運用しているプロジェクトも非常に多いですね。 まぁ、どのブランチ運用戦略も基本は単純です。 「master」は今本番環境で動作しているソースコードで、テストしてないコミットを混ぜるなころすぞ!!みたいな運用です。 GitFlowでは本番環境と一致するmasterブランチはおいそれとバージョンを引き上げられませんので、 他のコミットを取り込んで吸収するdevelopmentブランチを用意しておき、 リリースするぞ!というタイミングで入念なテストを行ってパスしたら、初めてmasterにマージされて運用が始まるという思想です。 GitHubFlowではこれは簡素になっており、 masterブランチへのプルリクエストだけでどんどんmasterに集約していく考えで運用しています。 > > 諸事情により1エラー足りとも、エラーを出すことが許されない状況でして、デプロイの手法について悩んでいます。 > > > ブランチ切ってプルリクエストの運用にしましょう。 質問文の懸念は「A機能」と「B機能」が同時に本番用のソースコードに混ざり、 デプロイされてしまうとエラーでWebサイトが停止してしまう!...というものですね。 この「A機能」と「B機能」をブランチとして別個のものにしておけば、 A機能だけ混ぜてデプロイしたいんだけどなぁと悩む事はありません。 A機能だけmasterにmergeで取り込ませてデプロイすれば良いのですから。 そもそもエラーの出るコードを混ぜてシステムを壊してしまう「B機能」なんて混ぜてはいけません。 ここはGitHubのSNS機能上で皆で検討・レビューを行ってからマージするプルリクエストという機能を利用しましょう。 これで本番環境でエラーが出たら誰の責任か?B機能がエラーが出るとわかってて承認ボタン押した間抜けにきまっているだろう?という話になります。 まぁ、DBの値が消えちゃった!?みたいな取り返しのつかないヤバイ不具合でなければ そんなにダメージは出ないのでさっさと直せば良いだけだと思いますけどね。 こんな所ですかね。 まずは「プルリクエスト」などのGitHubに備わっている機能、 「GitHubFlow」などのブランチ戦略に関して調査していきながら これは良さそう、これでやっていこうという運用を決めてみてくださいね。