WEBサイト公開後、顧客のサーバーにあるデータは顧客自身も触るし外製も触るしでGitのmainブランチのデータ＝顧客のサーバー状態とならず顧客のサーバーからいちいちデータをダウンロードしてGitにプッシュして・・・もうそうなるとGitで管理している意味がない・・・
万が一ダウンロードしたつもりのデータが顧客や外製が触っていたりしたらと思うと夜も寝られません。。
みなさまどのようにしているのでしょうか。
公開後はGitを破棄しているんでしょうか。
※ちなみに顧客のサーバーにgitを入れる。。。は不可みたいです
24時間つけっぱのＰＣで顧客のサーバーのデータを定期的に自動ダウンロード（or ファイルに変更があったら自動ダウンロードするとかが可能ならぜひに教えてください..）
→ 定期的に実行されるバッチを作ってmainブランチに自動でコミットプッシュする！
というのができたら顧客が触っていようと朝起きてmainブランチからブランチ切って作業してもフレッシュな気分になれるのでは？
そもそも顧客と外製が触ってもよい領域を決める
・・・なんか解決になっていない気がするけどとりあえずクリーンな気分で始めれる
なにかアイデアありませんでしょうか。
こういう状況悩ましいですよね。わかります・・・
まず技術的にどうこうの前に、業務的に所有権や責任などがどうなっているか、だと思います。
コードが外部と共有されて好き勝手に触れる状態で、精密な作業を要する開発にリスクがあるのは当たり前のことです。
そしてそれは顧客を含めた全体のリスクのはずなので、まずそれを周知して理解してもらう必要があって、その上で責任の境界をどこで引くかの相談だと思います。
そもそも顧客と外製が触ってもよい領域を決める
いずれにしてもこれが必要だと思います。誰が何に対しての責任を負うべきなのか明確にする必要があるでしょう。
責任が持てない領域を触るべきではありませんし、勝手に触らせるべきでもありません。他者の責任範囲を触る必要があるなら然るべき手順を設定します。
もちろんコストなどの関係ですっぱり境界を分けることをできない場合もあるでしょうが、そこはトレードオフです。
@m_nakai
Questioner→ 定期的に実行されるバッチを作ってmainブランチに自動でコミットプッシュする！
というのができたら顧客が触っていようと朝起きてmainブランチからブランチ切って作業してもフレッシュな気分になれるのでは？
サーバーのファイルを直接mainに統合するのは把握しづらいように思います。
自分だったらディレクトリとリポジトリを分けます。
upstream/ # サーバーからDLする専用
application/ # 自分の開発用
というスクリプトを書けば上書きを避けられると思います。
ちょっとうろ覚えなんですが、upstreamの更新をapplicationに反映するのはpatchかrsync、または単純にcpでやっていたと思います。
■プロジェクト運用的な話
まず最初に言えるのは既にリリース済みの製品に対して
何か運用を変えるのであれば他の方の回答にある通り、
「相談」は絶対に必須です。
※回答者の言葉馴染みの関係で「外製」を「外注」と記述します。
例ですが、
自身 => プロジェクト管理者(若しくは更に上長) => 顧客(外注)折衝
のように
現在の契約(責任問題)をどのように整理し、
SE側のプロジェクト管理をどのようにするのか等
具体的な方針を決める必要があると思われます。
ですので、質問者の方が提示した
個人的に思いついた案2
そもそも顧客と外製が触ってもよい領域を決める
こちらが現実的かと思います。
仮にソースコードの話だとしますが、
①自社のmainブランチ(最新かつデプロイ済み)
②顧客のサーバ(git未導入+自由に変更することができる)
③外注のmainブランチ(必ず①と同一であること)
とした場合、②に問題があることは
一目で分かるので相談しましょう。
■技術的な話
顧客のサーバーにあるデータ
これがソースコードの話か
DBの実データを何かしらに固めたモノかや
スキーマの話かいまいち分かりませんが…
もし実データであれば、
「そもそもGitで管理するべきでない」という回答になります。
その場合は可能であればデータの出力及び突合できるような
機能を実装してデータをマージするべきです。
みなさまどのようにしているのでしょうか。
※以下は自身が経験したRails案件の一例です
もしソースコードに変更を加えるようであれば
「feature/refactor-yyyyMMdd」のように新規(一時変更用)にブランチを作成し、
ローカル環境(もしくはステージング環境)での動作確認完了後
Pull-Requestを発行しレビュー完了後に
develop(開発用)ブランチにmerge => main(本番稼働)ブランチにmergeを実施します。
上記についてどうするかは全体的に相談してもらうとして、
GitHubで特定の操作が検知された場合に
自動的に何か仕掛けるということは
GitHub Actionsである程度は可能です。
個人的に思いついた案１
rsyncとgitを使う手法は割りと現実的にある印象。
運用で回避すべきなのは提案しているだろうけど
発注担当にその気がないならやらないので気苦労が多そう。
ほどほどに頑張ってください。
何に困っているのかよく分かりません。
顧客や外製がどのようなタイミングでデータを触ると、どのような問題が発生するのですか？
@m_nakai
Questioner状況がよくわからないので適当に答える
なにかヒントにでもなれば…
まず、コンフリクトをなるべくしないように構成を考えるのは必須だと思うので個人的に思いついた案2はできるだけやる。
git管理しなくてもいいデータならデータベースに入れてそちらで管理する。
それぞれが専門の領域を決めてそれぞれが専用のブランチを持ち、相手の領域に変更を入れてほしいときは、相手用のブランチを作ってプルリクエストを投げる。
適当なタイミングで、それぞれのブランチでここまでやってほしいというマイルストーンを協議して決めておく。それ以上は次回用のブランチ＆マイルストーンにする。
…とか？
addして差分が出ないようならコミットも作られないし、コミットが作られないならpushもされなかった気がするので、それ専用のブランチ(main-consumersとか)決めてダウンロード後、add/commit/pushするbashスクリプトでも作れば自動化は簡単に出来るかもしれない。
@m_nakai
Questioner顧客サーバー===jenkins==テストサーバー
| |
|====git===git
|
開発サーバー===顧客==GitHub
外製
3つクッションを配置する案も
あるとおもいます。
