Q&A
内容自体はとても良い回答ではあるのですが。
本質問は「一つの機能」を追加する場合に2つのファイルAとBを編集する必要があって、それを本番環境にホットデプロイするとして、万が一Bだけが更新された状態で動作してしまうと落ちるような状況でどうすればよいか？という質問だと解釈しました。
前提・実現したいこと・発生している問題
とあるWEBサービスにgitを使用して本番にデプロイする際に、git pull を使ってデプロイするとします。
例としてこれからデプロイするファイルが２つあり、A、Bとします。
・Aのみをデプロイした場合にはWEBサービスにエラーが出ない
・Bのみをデプロイした場合にはWEBサービスにエラーが出る
・A→Bの順番でデプロイした場合にはWEBサービスにエラーが出ない
・AとBのファイルは１つのファイルとして結合することはできない
・WEBサービスは秒間リスエストが非常に多いサイト
とします。
ファイルA、Bはほぼ同時にデプロイされるはずなので、そもそもファイルA,Bがどちらが先に反映されるかなど些細な問題なのですが
諸事情により１エラー足りとも、エラーを出すことが許されない状況でして、デプロイの手法について悩んでいます。
例えばgit pullを実行後、ファイルの反映がB→Aとなってしまう場合があれば、一瞬でもエラーが発生してしまう可能があります。
試したこと
ファイルAを先にデプロイをすればエラーが発生しないため、Aをデプロイ後、あとからファイルBをデプロイしております。
しかしあまり頭の良いやり方ではないのではと考え、何かいい方法はないかと探っておりますが思いつきません。
git pull時に反映する順番を選べるなど（comitした順番になるのか、容量なのか、タイプスタンプ、またはファイル名のソートなのかなど）の
情報があればぜひ試してみたいのですが、知りたいことの情報が出てこないため、ぜひ文献や情報、解決策、皆様のお知恵を拝借したいです。
補足情報（FW/ツールのバージョンなど）
申し訳ありませんが
・ファイルのアップロード順でエラーが発生してしまうこと自体が問題、というのは今回はなしにしてください。
・WEBサービスをメンテナンスモードにすることは許されていない状況です。
何卒、よろしくお願いいたします。
回答2件
0
自己解決
リリースブランチを2つに分けてデプロイするやり方にしました。
投稿2019/05/31 00:11
総合スコア158
0
この疑問はもっともで、それを対策する為にブランチという概念がGitには備わっています。
また、デグレを起こさない為のブランチ運用戦略というものがいくつも考案されています。
ブランチ運用戦略の内、有名なやり方は名前がついており、
GitFlowやGitHubFlowが有名です。
それをカスタマイズして運用しているプロジェクトも非常に多いですね。
まぁ、どのブランチ運用戦略も基本は単純です。
「master」は今本番環境で動作しているソースコードで、テストしてないコミットを混ぜるなころすぞ！！みたいな運用です。
GitFlowでは本番環境と一致するmasterブランチはおいそれとバージョンを引き上げられませんので、
他のコミットを取り込んで吸収するdevelopmentブランチを用意しておき、
リリースするぞ！というタイミングで入念なテストを行ってパスしたら、初めてmasterにマージされて運用が始まるという思想です。
GitHubFlowではこれは簡素になっており、
masterブランチへのプルリクエストだけでどんどんmasterに集約していく考えで運用しています。
諸事情により１エラー足りとも、エラーを出すことが許されない状況でして、デプロイの手法について悩んでいます。
ブランチ切ってプルリクエストの運用にしましょう。
質問文の懸念は「A機能」と「B機能」が同時に本番用のソースコードに混ざり、
デプロイされてしまうとエラーでWebサイトが停止してしまう！…というものですね。
この「A機能」と「B機能」をブランチとして別個のものにしておけば、
A機能だけ混ぜてデプロイしたいんだけどなぁと悩む事はありません。
A機能だけmasterにmergeで取り込ませてデプロイすれば良いのですから。
そもそもエラーの出るコードを混ぜてシステムを壊してしまう「B機能」なんて混ぜてはいけません。
ここはGitHubのSNS機能上で皆で検討・レビューを行ってからマージするプルリクエストという機能を利用しましょう。
これで本番環境でエラーが出たら誰の責任か？B機能がエラーが出るとわかってて承認ボタン押した間抜けにきまっているだろう？という話になります。
まぁ、DBの値が消えちゃった！？みたいな取り返しのつかないヤバイ不具合でなければ
そんなにダメージは出ないのでさっさと直せば良いだけだと思いますけどね。
こんな所ですかね。
まずは「プルリクエスト」などのGitHubに備わっている機能、
「GitHubFlow」などのブランチ戦略に関して調査していきながら
これは良さそう、これでやっていこうという運用を決めてみてくださいね。
投稿2019/05/24 09:03
総合スコア21158
tomatoさんの言う通り、回答にズレがあるようでした。質問の意図が悪かったため続けて詳細について追記させていただきます。
>GitFlowやGitHubFlowが有名です
もちろんGitFlowやGitHubFlowは存じており、プルリクもわかっておりますが、当方の質問の仕方が悪かったため返信させていただきます。
現在、プルリク後、releaseブランチからmasterへマージし、本番環境でgit pullするタイミングとしてください。
分割されたファイルA、Bについてですが、これは1つの機能を実装しており、ファイルBはAを参照している状態です。
Aのみをデプロイする場合は特にエラーが出ないのですがBのみデプロイした場合、参照先のAがないわけですからエラーとなってしまう仕様です。
通常、普通はファイルAとBを一緒にデプロイすると思うのですが、Bのファイルのほうが早くアップされ、コンマの差でファイルAがアップされた場合、
その間にアクセスがあった場合にはエラーが出てしまうというふうに認識してます。
本番へデプロイする方法として最終段階、本番サーバーにてgit pullにて対応するわけですが
git pull の細かい挙動として、本番のローカルのmasterブランチとリポジトリのmasterブランチの差分を変更するために
本番のローカルのmasterブランチのファイルA、ファイルBの中身が書き換わると思います。
しかし、同時に書き換わる仕様ではない場合、（１ファイルずつ書き換わっている）ファイルBのほうがタイミング早いと、エラーとなってしまいます。
そのため
・そもそものgitの仕組みが同時に書き換えている
のであれば問題ありません。
また、仮に書き換えている順番があるのであればcomitの順番であったり、ファイル名のソート順などで指定できるのであれば対応できるのですが
どのような順番を選ぶ基準で選ばれているのかがソースを見てもわからないため質問させていただいている次第となっております。
もしご存知でしたらお力を貸して頂けましたら幸甚に存じます。
よろしくお願いいたします。
後出しな上に園児ニアじゃねえかという話で
状況をかなり下方修正する必要があるので回答する気力が大分失せました。
気力が回復したら文章を全部リテイクするかも知れません。
miyabi-sun様
申し訳ありません。投稿後、内容を追記した部分もありましたため
タイミング的に後出しになってしまった可能性もあるかと思います。
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。