[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[cvs-ml 435] RE: directoryのみのexport
ご丁寧にありがとうございます。
あまり詳しく書くと、本題からそれてしまうと思い、あのような書き方に
なりました。どうも済みませんでした。
環境としては、
・本番機(複数:プロジェクト別)
・開発機(本番機と対になるので、本番機と同数)
・ライブラリ管理サーバ(1台) で、全てUNIXです。
ライブラリ管理サーバの構成としては、
・レポジトリ
・entryディレクトリ (/~各プロジェクト/entry/)
・ftpディレクトリ (/~各プロジェクト/ftp/)
・recoveryディレクトリ (/~各プロジェクト/recovery/)
条件として
・ライブラリ管理者が行なう作業は、安定後すべてスケジューラで
自動化する。ライブラリ管理者は終了結果のcheckのみ。
・各開発機にはCVSを導入することは可能だが、本番機には導入
しない(出来ない)。
流れとしては、
まず、各開発担当者がライブラリ管理サーバのftpディレクトリに
本番機への配布を希望するモジュール(ftpディレクトリ下に本番環境
と同じフルパスで)を置きます。
それをライブラリー管理者が各本番機へftp(tarでまとめて)する。
また、entryディレクトリにcopyし、"cvs commit"し、登録する。
entryとftpディレクトリを別にした理由は"cvs commit"のみを実行すれば
登録できるように、entryディレクトリには常にcheckoutした状態の環境に
したい、また本番機に送るものは、更新ファイルのみにしたい
(他のモジュールやCVS管理ファイルは送りたくない)という理由からです。
配布・登録完了後は、ftpディレクトリ以下をremoveし、ディレクトリ情報
だけを登録したものを再び、exportしようと考えました。
かなりの数を管理するため、登録・配布は自動化するしかありません。
且つ登録はまだしも配布でミスすると、かなりのユーザに迷惑をかけ、
大問題になります。そのため、作業は出きるだけ単純化しなくてはなりません。
本来ならば、本番機にCVSを導入し、リモートでcheckoutすれば良いのですが、
色々な理由からCVSの本番機への導入は難しい状況です。
またファイル転送結果を一括して確認するためにも管理サーバ側からの
ftpが適切と判断しました。
トラブル時の前Versionの戻しなど、考えなくては
ならない事柄がまだまだ沢山あります。
つまらない質問をするかもしれませんが、宜しくお願いします。
---
瀬戸 敏博 <cte668@esq.dentsu.co.jp>