n2p blog

キャンペーンやSNSの
“ためになる”情報を
執筆しています。

複数人でのファイル同時更新のセーフティーな運用方法

案件もいよいよ大詰め、ローンチまであと72時間!だが動かないシステム!!崩れる表示!!!そんな時、複数人で一つのサーバを同時に編集せねばならない戦場のような瞬間が極稀に発生します。
この極限状態をどうすればより安全にきりぬけていけるのか?という考察です。

ファイルの先祖返りという悲劇が起こる原因

そのような状況でありがちなのは、以前作業したデータが数時間前のものに戻っている!さっき更新したものが更新されていない……!という現象です。
複数人で作業していてその事態が発生する原因は、以下の3つに集約されます。

  1. 別の階層に同じ名前のファイルを間違ってアップロード(以下UL)してしまう
  2. 作業する直前に作業するファイルをダウンロード(以下DL)しておらず、結果作業ファイルやULファイルが古くなってしまい、バックデートする
  3. 複数の人が同時に同じファイルを操作して時間差でULしてしまい、どちらかの変更が失われてしまう

今回書く運用でカバーできるのは1.と2.までで、3.についてはお互いの声がけで気をつけるのが全て!という感じです。slackとか使うといいんじゃないでしょうか。

下準備

filezillaを用意する

DLページ

http://osdn.jp/projects/filezilla/

使い方の基礎

http://osdn.jp/magazine/10/01/30/0741238

必須の設定

http://me2.jp/blog/html/%EF%BD%86%EF%BD%89%EF%BD%8C%EF%BD%85zilla_hidden.html
隠しファイル(例えばhtaccess)を上書きしてしまう事態を避けるため、隠しファイルは表示できるようにしておきましょう

同期機能

http://daredemopc.blog51.fc2.com/blog-entry-1031.html
同期機能は別の階層に同じ名前のファイルを間違ってULしてしまう事故を避けるために必須なので、常にonにしておきましょう!

gitを用意する

http://www.backlog.jp/git-guide/intro/intro1_1.html
こちらの、「Gitの基本」「チュートリアル1 Gitの基本」の項目だけ準備しましょう。
共有リポジトリは今回使わないので、ファイルのコミットの方法までマスターできれば十分です。
マメにファイルをコミットしておくことで、自分のローカル環境にだけでもサーバの変更履歴を残していこうという作戦です。

作業フロー

1.サーバからデータをDLする(初めてDLする時)

1-1.FileZillaでサーバからサーバのファイル全体(もしくは自分の作業する可能性のある領域全体)をDLしてきます

safety-death-march1-1-1

フォルダ名は、閲覧環境のドメインと同一にするなど工夫して、似たような名前の他のサーバなどと間違えにくいものにしましょう。
たとえば今回は、サーバのドメインから、「n2p.cpdev.jp」にしました。

safety-death-march1-1-2

前述したように、作業の際は必ずローカルとリモートの表示フォルダを同期しておきましょう。表示階層を同期しないと、ULミスが発生しやすくなります。
今同期モードかは、上記の図の赤枠内、右のボタンの表示でわかります。
また、必要に応じてファイルの比較を有効にしておいても便利です。上記の図の赤枠内、右のボタンの表示で切り替わります。

1-2.リポジトリを作ります

safety-death-march1-2-1

まずはgitのリポジトリを作りましょう。ダウンロードしたフォルダの一番上の階層(FileZillaで同期表示する際に一番上になる改装)をエクスプローラで開き、右クリックして出るメニューで「ここにリポジトリを作る」を選択。

safety-death-march1-2-2

次に出るダイアログのチェックボックスを押さずにそのままOKを押します。

safety-death-march1-2-3

「空のリポジトリを作成しました」と出るのでOKを押します。

1-3.コミットします(記録開始)

safety-death-march1-3-1

ではダウンロードしたばかりの初期状態を記録してしまいましょう!
エクスプローラーで右クリックし、「Gitコミット->”master”」を選択。

safety-death-march1-3-24

1.メッセージ欄は必須なので、「記録開始」と入れます。
2.「すべて」をクリックして、フォルダ内のすべてを記録対象に。
3.「OK」をクリックします。

safety-death-march1-3-5

ダイアログが表示されるので、プログレスバーが端まで行くのを待ちます。「成功」と出たら「閉じる」ボタンをクリックします。
おめでとうございます!まずはこれで、初期状態のセーブポイントが出来ました。
では次は具体的な作業フローに入りましょう。

2.作業する

2-1.FileZillaでサーバから、サーバのファイル全体を再びDLしてきます

もう一度、サーバのファイル全体を再びDLしてきます。同じサーバで同時に作業している人がいない場合は、この工程を省けます。
ただし、同じサーバで同時に作業している人がいる場合は、必ずもう一度DLしてきましょう。前回のDLから時間が経って、ファイルが更新されているかもしれません。
更新ファイルが明確に伝わっているのならばそのファイルだけをDLしておけば全体をDLする必要ありません。しかし、大抵同時に作業しないとならない状況では、細かく更新ファイルを伝え合うのもおぼつきません。
なにより、ひとつひとつDLしていると、DLし損なうファイルが1つ2つ、出てきてしまう可能性があります。なので、なるべくサーバのファイル全体をDLしてきてしまうことを推奨します。
(gitを本格的に使われている方にとっては、マメにPullするようなイメージですね。)

2-2.サーバの内容に変更があるか調べ、サーバの変更を記録します。

ではもう一度、エクスプローラーで右クリックし、「Gitコミット->”master”」を選択。

safety-death-march2-2-1

メッセージ欄に記録内容を入力します。そして「すべて」をクリックして、フォルダ内のすべてを記録対象に。そして「OK」をクリックします。
あとはさきほどと同じようにダイアログが表示されるので、プログレスバーが端まで行くのを待ちます。「成功」と出たら「閉じる」ボタンをクリックします。

2-3.作業します

粛々と作業します。

2-4.変更ファイルをFileZillaでサーバにULします

safety-death-march2-4-1

変更ファイルをFileZillaでサーバにULしましょう。
ここでも必ずローカルとリモートの表示フォルダを同期しておきましょう。しつこいようですが表示階層の同期は超重要です。

safety-death-march2-4-2

ファイルをUL・DLするときには、上記のようなダイアログが表示されます。
こちらでの選択肢は、動作を「上書き」下のチェックボックスは「常にこの動作を利用」且つ「現在のキューのみに適用」がお勧めです。
「現在のキューのみに適用」をチェックすると、自動で「常にこの動作を利用」にチェックが入ります。
「常にこの動作を利用」にのみチェックすると、常に確認することなくファイルを上書きしてくれますが、これは危険であると考えています。UL直前に間違えてサーバのものをDLしてしまうなどしてしまうと、悲劇です。一つ一つの動作に自覚的であれるようにした方が、結果的に安全です。
こちらでしっかり動作を確認し、修正が完了!となったら次の作業です。

2-5.コミットします(作業内容を記録)

safety-death-march2-5-2

無事に修正が終わったら、記録してしまいます。
メッセージ欄に記録内容を入力します。そして「すべて」をクリックして、フォルダ内のすべてを記録対象に。そして「OK」をクリックします。
あとはさきほどと同様、ダイアログが表示され、プログレスバーが端まで行き、「成功」と出ることでしょう。「閉じる」ボタンをクリックします。

おめでとうございます!これで編集がひとつ完了しました。これからは「2.作業する」のフローを回していけばOKです。
なるべくひとつの修正をしたらまめにULしてコミットして、再びサーバからDLしてきたほうがいいです。
誰かと同時に作業をしている際は、サーバからDLして同期をとる頻度が上がれば上がるほど、先祖帰りの事故は防げます

質疑応答

Q.いちいち全部DLするのは時間がかかるしめんどくさい

A.自分が触らないことが明確になっている領域についてはDLしないのも手です。
ただし、別の階層に同じ名前のファイルを間違ってULしてしまう事故が起きた時リカバリできなくなりますので、運用はくれぐれも慎重に。
また、ファイルがバックデートする事故は、DLを怠らなければそもそも起こりません。理論上は、編集したいファイルのみを作業の直前に都度DLしなおせばいいはずです。
しかし作業をしているさなかにいちいちDLすることに気が回るのかというと、とても疑問です。人間時々はミスをするものなのですよね。
なので、たとえ急いでいてもフローの通りに作業を進めたほうが、結果的に事故を減らせ、安定して仕事ができると思います。

Q.安全である以外に何かメリットはあるか?

この方法はローカルにサーバの変更記録が全部残せるので、やっぱり前の状態に戻したいなどの状況の時、リカバリが早いです。
また、制作用サーバと公開用サーバを分けて運用するとき、本番化の際にULするための差分ファイルの抽出が圧倒的に楽になります。

Q.全部DLすると間違って上書きしてしまわないか?

A.FileZillaの同期機能で程度カバーできるはずです。
必ず同期機能をonにしておきましょう。
また、前項と被りますが、万が一に備えて頻繁にDLしておきましょう。間違えてULしたとしても、DLしたばかりのものをULする限りは、ファイルの中身は変わらないはずです。

Q.PCにgitを入れることができない場合の防衛策は?

A.定期的にサーバのバックアップをとりましょう。そして一つ一つのフォルダに取得日時を明記しておきましょう。

safety-death-march3

スポット的に上書きする際には、ULの前にサーバー上の同名ファイルにbakとつけ、消したり上書きしないようにするという方法もあります。UL後に正常に動作することを確認してから、bakファイルを消します。(消すのを忘れずに。サーバーがbakファイルのゴミでいっぱいになってしまいます)

それでは皆様、頑張りましょう~♪