MediaWikiとWordPressのインストールを含むWebサイト開発プロジェクトをバージョン管理するには良い方法はありますか？

Question

私はMediaWikiとWordPressのインストールが含まれているWebサイトのバージョン管理手順を理解しようとしています。私はちょうどこれらについて考え始めて、おそらくあまりにも迅速かつ曖昧な質問をしています。

は、Webサイトのルートが

~/public_html 

様々な静的なHTMLページ

~/public_html/page1.html 
~/public_html/dir/page2.html 
... 

があるとMediaWikiの

~/public_html/wiki/ 

とワードプレス

のインストールがあると言います

とデータベースのバックエンドを持つ可能性のある他のwebapp

私はSubversionを使用している場合はいくつかの質問ではない明確な

• 私にはありますが、私の最初のステップは何ですか？私のWebサーバマシンで/ public_htmlが既に実行されているので、最初に完全な/ public_htmlを自分のローカル開発用コンピュータにダウンロードしてから、プロジェクトとして自分のsvnサーバ（別）にコミットする必要がありますか？私はSubversionを使ってバージョン管理されている他のソフトウェアプロジェクトを持っています。

• 私がデプロイするときにチェックアウトするだけですか？つまり、サーバーで使用されているWebサイトがリポジトリの作業コピーになりますか？ MediaWikiとWordPressのバージョンが正しく設定されますか？また、.svnディレクトリはどうですか？それは公開されませんか？

• さらに、/ public_htmlのファイルをバージョン管理すると、public_htmlのファイルで合理化された方法でデータベースをバックアップするにはどうすればよいですか？

• 代わりにMercurialを使用すると、私はpublic_htmlをリポジトリとして使用でき、必ずしもリポジトリをクローンする必要はありませんか？

Answer 1

私はソース管理、スクリプト、および展開手順を使用して、wordpress、phpbb、カスタムWebアプリケーションなどのWebアプリケーションプロジェクトをほとんど管理していません。長年にわたり、私はこれらを洗練しましたが、今は私にとってうまくいくような素晴らしいフレームワークを持っているので、同様の問題に直面している他の人にも適しています。ここで

は、全体的な戦略についてのいくつかの一般的なポイントです：

• 私は本番サーバー上のSCMとソースファイルを持っていることはありません。私はそこに置く理由は見当たりませんし、通常、サーバー侵害の場合にはリポジトリを公開したくありません。プロダクションサーバ上のアプリケーションは、最新の安定した最新リビジョンしか持っていません。プロジェクトファイル、ドキュメント、単体テストなどは必要ありません。必要のないものはありません。セキュリティとアプリケーションの安定性の観点から、このことが非常に重要であることがわかりました。
• これをSCMの議論に変えないでくださいが、私の目的では水銀（およびgit）がSVNより優れていることがわかりました。あなたはどんな「サーバ」も必要とせず、リポジトリは維持しやすくなります。
• プロジェクトごとに別々のリポジトリを作成します。Mercurialリポジトリは安価で軽量です。すべてのプロジェクトを独自のリポジトリに保存すると、大きな柔軟性が得られます。だから誰も "public_html"の大きなリポジトリはありません。
• 私は、開発マシン上のローカル水銀リポジトリを使用しています。すべてがそのままバックアップされます（追加のマシン、外付けドライブ、クラウドバックアップなど）。プロジェクトのディレクトリを指定するだけで簡単にコードを共有できます。時にはリポジトリをdropboxに保存しているので、どこからでもアクセスできます。
• デプロイメントは、デプロイスクリプトによって自動的に行われます（詳細は後で説明します）。これは、目的のリビジョンをエクスポートし、編集してサーバーにアップロードします。
• データベースダンプはSCMに格納されません。実際のプロジェクトでは実用的ではありません。私はデータベース構造体のダンプをSCMに保存し、構造が変更されるといつでも更新します（私はこれにmysql dumpまたはphpmyadminを使用します）。場合によっては、スケルトンデータのダンプをSCMに構造（デフォルト、ルックアップ値などのテーブル）と共に格納することが理にかなっています。
• データベースのバックアップは、本番サーバーで実行される自動スクリプト（が正常に動作する）によって行われます。データベースをダンプし、アーカイブし、ファイルをローテーションします（毎月、毎週、毎日）。毎日オフサイトの場所にバックアップダンプファイルをダウンロードするスクリプトもあります。これは、中規模のデータサイズが比較的小さいプロジェクトでうまく機能します。明らかに、これは大きなデータベースでは変更する必要があります。
• 私は、通常、開発と本番用に別々のデータベースインスタンスを用意しています。プロダクションデータベースを可能な限り利用しないでください。私が何かをテスト/デバッグする必要があるとき、私はライブデータのコピーで私の開発データベースを更新します。
• ステージング/単体テスト用の運用サーバー上にアプリケーションの2番目のコピーがあることがありますが、ここで説明するにはあまりにも多すぎます。
• すべてのデプロイメントはSSH経由でトンネリングされます。これはサーバー上で唯一許可されている接続です（http/sを除く）。 SSHキーファイルを開発マシンに保存します。また、VPNをトンネルとして使用することもできます。
• 私は、Linux/BSDプロダクションサーバを想定しています。これらはすべて、Windowsサーバー上ではまったく異なっています（通常はより困難です）。 Windows、Mac、Linux開発マシンでこれらの手順を使用しましたが、すべてのツールはすべて利用可能です。

あなたの質問のいくつかに答えるために、私はそれを逆にしています。開発マシン上の作業環境から始めます（Webサーバーとデータベースを完備しています）。アプリケーションをそこで動作させ、テストしてください。必要に応じてローカルリポジトリへの変更をコミットします。アプリケーションのデプロイメントが完了したら、デプロイスクリプトを実行して本番サイトを自動的に更新します。

（水銀、gitの、SVNのすべてがあなたのリポジトリから作業ディレクトリを作成し、エクスポートコマンドを持っている）ローカルの一時deployディレクトリに

• 輸出希望リビジョン：

  マイデプロイスクリプトは、このような何かを展開されたディレクトリを変更して、ライブ展開に適したものにします。これには、設定ファイルの変更、データベース名、パス、ログ設定、デバッグレベルの変更などが含まれます。スクリプト、sed、awk、grepなどのコマンドラインツールが必要です。

• 必要に応じて、SCMリビジョンデータ、展開日などからversion.txt（または任意の名前）ファイルを生成します。これがサーバーにアップロードされます。
• SSHエージェントに自分のSSH鍵を追加する（毎回パスワードを使用しないようにする）。
• SSH経由でトンネリングされたrsyncを使用して、すべてをサーバーに同期させます。サーバをrsyncの宛先として適切に設定する必要があります。rsync exclude/includeフィルタを使用して、不要なすべてを除外します（しばしば。* .htaccessを除く）。
• SSHのリモート実行機能を使用して、サーバー上でコマンドを実行して、特別なアクセス許可（たとえば、Wordpressのアップロードディレクトリへの書き込み権限）を設定するなどのタスクを実行します。
• スクリプトは場所の展開になったら、私に素敵な「展開の成功」メッセージ:)

それだ付け楽しくなります。スクリプトを実行し、ライブサーバーに行き、すべての作業が完了したことを確認します。

これが役に立ちます。