数か月前、私はSubversionとGITを調べましたが、がっかりしました。ソースコードは問題なく処理されますが、他の側面は処理されません。たとえば、バージョン管理下のWebサイトは、ファイル/ディレクトリの所有権、ファイル/ディレクトリの読み取りおよび書き込みアクセス、アクセス制御リスト、タイムスタンプ、データベースの内容を管理する必要があります。および外部リンク。 1か月前のバックアップからリロードするのと同じくらい完全に復帰できるバージョン管理システムはありますか?
バージョン管理システムの役割について混乱しています。これは、実行中のWebサイトのバックアップシステムを意図したものではありません。静的コンテンツを管理するという非常に優れた機能を備えているため、制御された方法で本番環境に移行できます。タグ付けと自動チェックアウトを適切に使用することで、変化の激しいサイトでもバージョン管理システムを維持できます。
バージョン管理システムは、先月のサイトの外観から今日の外観に至るまでの経緯を伝えることができます(少なくともソース管理されているコンポーネントの場合)。ウェブサイトを再構築するために必要なすべてが含まれている必要があります(動的コンテンツを除く)。他の人が述べたように、権限と所有権への変更はスクリプト化する必要があり、そのスクリプトはバージョン管理に含まれています。
Webサイトのアクセス許可は通常、非常に簡単です。 (基本的に、Webサーバーがすべてのコンテンツを読み取り、ほとんど書き込むことができないことを確認する必要があります。)WebサーバーSubversionによる書き込みが必要ないくつかのディレクトリのディレクトリ所有権を除いて、おそらくgitは確実に権限を処理します。 Webサーバーによって書き込み可能なディレクトリには、通常、動的コンテンツ(Webサイトから作成および更新)が含まれ、Webサイトのソースとは別に管理されます。
あなたのWebサイトに複雑なアクセス許可とACLが設定されたWebサイトで作業するように依頼された場合、そのWebサイトの管理に使用されるプロセスについて深刻な懸念があります。バージョン管理システムを実装し、それにACLを移動することは、私が真剣に検討するソリューションの1つです。
ブログのエントリやコメントなどの動的コンテンツは、通常、サイトの構築に使用されるバージョン管理ではなく、データベースや他のデータストアに含まれています。データストアは、コンテンツのバージョン管理を提供するように構成できます(このソフトウェアと同様)。多くのWikiは、バージョン管理システムを使用してリビジョンを追跡します。
編集:
私が使用している修正は、(a)バージョン管理がまったくない、(b)本番サイトがマスターサイトである、(c)何かが変更されるたびにアーカイブする、(d)アーカイブスクリプトがACLなどのジャンクを削除する、および(e)インストールスクリプトは、他のジャンクのようなファイル権限を修正します。
これらの問題は、サイトをバージョン管理システムにインポートし、マスターサイトがそのシステムを通じて更新されるようにプロセスを変更することによって処理できます。 (a)、(b)、および(c)は、バージョン管理によって直接処理されます。リリースにタグを付けて、(c)をよりよく機能させることができます。 (d)サイトを変更するデプロイメントシステムしかない場合、通常は問題になりません。サイトのコンテンツにACLが必要なことは一度もありません。
(e)最初の作成および大きな変更時にのみ実行する必要があります。また、バージョン管理からサイトを更新し、頻繁に実行するスクリプトが含まれている場合もあります。これらのスクリプトは、嫌悪管理システムでサイトを維持している場合、非常に単純になる傾向があります。
しかし、なぜ誰もがこれを行うための一般的なシステムを構築していないのですか?
バージョン管理システムを使用している場合は必要ないためです。
バージョン管理システムはこのすべてを追跡できますが、追跡しません。
CVSとSubversionはどちらも、使用している場合に追跡する必要があるものを追跡します。バージョン管理システムを使用していないため、追跡する必要のあるものも追跡しません。これらは、バージョン管理システムを使用しているときに追跡する必要があるものを追跡します。
私は、バージョン管理を使用してコンテンツを管理するいくつかのサイトと協力してきました。ステージングサイト、展開の頻度、更新の完全性については、すべて要件が異なりました。サイトがバージョン管理に入ると、残りの要件は比較的簡単に満たすことができました。 CVSとSubversionの両方のドキュメントで、可能な更新方法が提案されています。
バージョン管理されたコンテンツ内の特定の領域へのアクセスを制限するために、ACLが必要になる場合があります。しかし、私は信頼に基づいて仕事をする傾向があります。バージョン管理により、誰がいつ何をしたかを簡単に確認できます。ファイルを再フォーマットしない場合、誰がいつどの行を追加したかを示すファイルの注釈付き履歴を簡単に取得できます。
それらのすべてとそれらのどれも。
質問の親密な方法で、これらの詳細をソース管理で直接管理することは悪い考えです。
ただし、bashスクリプト(* nix)またはpowershellスクリプト(Windows)を記述して、これらの目標の一部またはすべてを達成することができます。このスクリプトはソース管理に保存できます。
次に、そのスクリプトをビルドアーティファクトの1つにして、デプロイメントの一部として実行できます。
IMHOバージョン管理システム自体は、そのような方法で使用することを意図していません。
しかし、私がしがちなのは、ソース管理からバージョンを取得できることを確認することです。1つのビルドファイル/ Powershellファイルを実行するだけで、すべてが再び稼働します。
このためにあなたはする必要があります:
私はあなたがあなたの場合に必要なものは 構成管理 ツールだと信じています。私が使用したものは puppet です。
あなたを引用:
ファイル/ディレクトリの所有権、ファイル/ディレクトリの読み取りおよび書き込みアクセスの管理、
私はそれを1行で行いました(ユーザーが存在することを確認し、ディレクトリが存在することを確認するなど)...
アクセス制御リスト、
これがWindows ACLの場合、Windows用の特定のCMツールがあります...
タイムスタンプ、
ここでも、人形スクリプトの1行にある touch unixコマンドでこれを行うことができます。
データベースの内容。
それは多くのフレームワークで構築されています。
および外部リンク。
それについて何も知らない。
もちろん、構成管理コードを記述した後、バージョン管理システムにそれを配置(または関係するシステムで取得)することができます。あなたはそれらから逃れることはできません:-)。
すべてのデジタルドキュメントのすべての側面を管理する究極のバージョン管理システムがあります。これはXanaduと呼ばれ、ファイルシステムなどが一般的になる前であっても、1960年に Theodor Holm Nelson によって作成されました。したがって、理論的にはすべてが完全に解決されます。実際には、XanaduはNelsonの想定どおりに実装されたことはありませんが、Webやバージョン管理システムなど、より多くの特殊なシステムに影響を与えました。ネルソンの作品は、まだ一読する価値があります。そして、すべての側面を管理する一般的なVCSがない理由についての質問に答えるかもしれません。