m_nakai
@m_nakai

Are you sure you want to delete the question?

Leaving a resolved question undeleted may help others!

顧客のサーバー状態をgitで管理したいのですが方法ありませんでしょうか

常時、顧客のサーバーの状態とGitのデータを同期(?)したい

WEBサイト公開後、顧客のサーバーにあるデータは顧客自身も触るし外製も触るしでGitのmainブランチのデータ=顧客のサーバー状態とならず顧客のサーバーからいちいちデータをダウンロードしてGitにプッシュして・・・もうそうなるとGitで管理している意味がない・・・
万が一ダウンロードしたつもりのデータが顧客や外製が触っていたりしたらと思うと夜も寝られません。。

みなさまどのようにしているのでしょうか。
公開後はGitを破棄しているんでしょうか。

※ちなみに顧客のサーバーにgitを入れる。。。は不可みたいです

個人的に思いついた案1

24時間つけっぱのPCで顧客のサーバーのデータを定期的に自動ダウンロード(or ファイルに変更があったら自動ダウンロードするとかが可能ならぜひに教えてください..)
→ 定期的に実行されるバッチを作ってmainブランチに自動でコミットプッシュする!
というのができたら顧客が触っていようと朝起きてmainブランチからブランチ切って作業してもフレッシュな気分になれるのでは?

個人的に思いついた案2

そもそも顧客と外製が触ってもよい領域を決める
・・・なんか解決になっていない気がするけどとりあえずクリーンな気分で始めれる

なにかアイデアありませんでしょうか。

0

7Answer

こういう状況悩ましいですよね。わかります・・・

まず技術的にどうこうの前に、業務的に所有権や責任などがどうなっているか、だと思います。

コードが外部と共有されて好き勝手に触れる状態で、精密な作業を要する開発にリスクがあるのは当たり前のことです。
そしてそれは顧客を含めた全体のリスクのはずなので、まずそれを周知して理解してもらう必要があって、その上で責任の境界をどこで引くかの相談だと思います。

そもそも顧客と外製が触ってもよい領域を決める

いずれにしてもこれが必要だと思います。誰が何に対しての責任を負うべきなのか明確にする必要があるでしょう。

責任が持てない領域を触るべきではありませんし、勝手に触らせるべきでもありません。他者の責任範囲を触る必要があるなら然るべき手順を設定します。

もちろんコストなどの関係ですっぱり境界を分けることをできない場合もあるでしょうが、そこはトレードオフです。

5Like

Comments

  1. @m_nakai

    Questioner

    > そもそも顧客と外製が触ってもよい領域を決める
    > コードが外部と共有されて好き勝手に触れる状態で、精密な作業を要する開発にリスクがあるのは当たり前のことです

    そういうことに対するリスクを考えていない先方の多くが先祖帰りしたりすると烈火のごとくお怒りになる場合が多いので困ります・・・


    > もちろんコストなどの関係ですっぱり境界を分けることをできない場合もある

    触ってよい領域を決め打ちしたいんですけど
    このケースが多すぎるので、ディレクトリーを触ってよい領域を
    まったくわかってない営業に説明にしてもらうのもなんだか
    現実的ではないような気がしています。。うーん。。

→ 定期的に実行されるバッチを作ってmainブランチに自動でコミットプッシュする!
というのができたら顧客が触っていようと朝起きてmainブランチからブランチ切って作業してもフレッシュな気分になれるのでは?

サーバーのファイルを直接mainに統合するのは把握しづらいように思います。
自分だったらディレクトリとリポジトリを分けます。

upstream/ # サーバーからDLする専用
application/ # 自分の開発用
  • upstreamにサーバーからDL
    • 変更があればupstream にコミット、エラーメッセージ
    • 変更がなければ application をサーバーにアップロード

というスクリプトを書けば上書きを避けられると思います。

ちょっとうろ覚えなんですが、upstreamの更新をapplicationに反映するのはpatchかrsync、または単純にcpでやっていたと思います。

3Like

■プロジェクト運用的な話

まず最初に言えるのは既にリリース済みの製品に対して
何か運用を変えるのであれば他の方の回答にある通り、
「相談」は絶対に必須です。

※回答者の言葉馴染みの関係で「外製」を「外注」と記述します。

例ですが、
自身 => プロジェクト管理者(若しくは更に上長) => 顧客(外注)折衝

のように
現在の契約(責任問題)をどのように整理し、
SE側のプロジェクト管理をどのようにするのか等
具体的な方針を決める必要があると思われます。

ですので、質問者の方が提示した

個人的に思いついた案2
そもそも顧客と外製が触ってもよい領域を決める

こちらが現実的かと思います。

仮にソースコードの話だとしますが、

①自社のmainブランチ(最新かつデプロイ済み)
②顧客のサーバ(git未導入+自由に変更することができる)
③外注のmainブランチ(必ず①と同一であること)

とした場合、②に問題があることは
一目で分かるので相談しましょう。

■技術的な話

顧客のサーバーにあるデータ

これがソースコードの話か
DBの実データを何かしらに固めたモノかや
スキーマの話かいまいち分かりませんが…

もし実データであれば、
「そもそもGitで管理するべきでない」という回答になります。
その場合は可能であればデータの出力及び突合できるような
機能を実装してデータをマージするべきです。

みなさまどのようにしているのでしょうか。

※以下は自身が経験したRails案件の一例です

もしソースコードに変更を加えるようであれば
「feature/refactor-yyyyMMdd」のように新規(一時変更用)にブランチを作成し、
ローカル環境(もしくはステージング環境)での動作確認完了後
Pull-Requestを発行しレビュー完了後に
develop(開発用)ブランチにmerge => main(本番稼働)ブランチにmergeを実施します。

上記についてどうするかは全体的に相談してもらうとして、
GitHubで特定の操作が検知された場合に
自動的に何か仕掛けるということは
GitHub Actionsである程度は可能です。

2Like

個人的に思いついた案1

rsyncとgitを使う手法は割りと現実的にある印象。
運用で回避すべきなのは提案しているだろうけど
発注担当にその気がないならやらないので気苦労が多そう。
ほどほどに頑張ってください。

2Like

何に困っているのかよく分かりません。
顧客や外製がどのようなタイミングでデータを触ると、どのような問題が発生するのですか?

1Like

Comments

  1. @m_nakai

    Questioner

    > 何に困っているのかよく分かりません。

    伝わらず申し訳ない。よくある例をあげると

    Gitを使ってWebサイト作成 → 無事公開 →
    公開後メンテナンス依頼発生 → Gitのデータが最新だと思って編集して差分をアップ
    → 実は先方が触っていた → 先祖帰り発生 → まじっすか

    みたいな感じです。
    先方が触っている場合もあるし先方が雇っている外製さんに依頼して編集されている
    場合もある。なので開発時のGitのデータがどうしても古い状態になってしまう。

    そして、Gitのデータが最新かどうかが怖いので
    顧客のサーバーから作業範囲のデータをFTPでダウンしてくる
    Gitのmainブランチに入れてみる → 変更あれば触ってるからプッシュ →
    mainブランチからブランチ切ってメンテ作業する

    みたいな感じでやってたんですが、めっちゃ効率悪いなと。

    みなさまどうやってこの問題クリアしているのかなと思った次第です。




状況がよくわからないので適当に答える
なにかヒントにでもなれば…

まず、コンフリクトをなるべくしないように構成を考えるのは必須だと思うので個人的に思いついた案2はできるだけやる。

git管理しなくてもいいデータならデータベースに入れてそちらで管理する。

それぞれが専門の領域を決めてそれぞれが専用のブランチを持ち、相手の領域に変更を入れてほしいときは、相手用のブランチを作ってプルリクエストを投げる。

適当なタイミングで、それぞれのブランチでここまでやってほしいというマイルストーンを協議して決めておく。それ以上は次回用のブランチ&マイルストーンにする。

…とか?

addして差分が出ないようならコミットも作られないし、コミットが作られないならpushもされなかった気がするので、それ専用のブランチ(main-consumersとか)決めてダウンロード後、add/commit/pushするbashスクリプトでも作れば自動化は簡単に出来るかもしれない。

1Like

Comments

  1. @m_nakai

    Questioner

    顧客や顧客が雇ってる外製が、同じGitを触って管理してくれるのが
    理想なんですけどね・・・
    そしたらご意見いただいた内容で確かに行けると思うんですけどね(たぶんBacklogとか使う感じですかね)

    それはハードルが高い感じでございまする・・

顧客サーバー===jenkins==テストサーバー
         |      |
         |====git===git
                |
      開発サーバー===顧客==GitHub
              外製

3つクッションを配置する案も
あるとおもいます。
              

1Like

Your answer might help someone💌