それでは始めましょう。
数年前、問題がありました。それは、タスクごとにサーバー上に個別のテストサイトを準備するのはかなり面倒だったことです。 当時、リポジトリでは1つのトランクがすべての開発者と1つのテストサーバーに使用されていました。 もちろん、大規模なタスクの場合、個々のインスタンスを手動で準備しましたが、これは通常のソリューションよりも必要な手段でした。 これはすべて、開発中に定期的にコードの競合を引き起こし、最も悲しいことは、別のタスクの一部として実行される作業のために、1つのタスクが予期せずに故障することです。
プロジェクトの機能について少し
これは私たちの主要なプロジェクト（サイトalawar.ru、alawar.comなど）の1つであり、その本質は異なる言語の異なるドメインから異なるコンテンツを提供することです。 1つのプロジェクトのフレームワーク内で、約100のドメインとサブドメインが関係しています。コードの変更には、バグトラッカーの対応するチケットが伴います。 さまざまな規模のチケットが週に数十回行われます。 各チケットを個別にテストする必要があります。
この問題を解決する場合、リポジトリは重要ではありません。別のブランチで開発を行うことができるものであればどれでも使用できるため、この問題に特に焦点を合わせません。
私たちのオプションは何でしたか
1.サーバー構成を手動で作成する実際、私たちはこれを長時間行いましたが、すべてのタスクではありません。 本当に長い時間がかかりました。 したがって、必要なものだけを作成し、可能であれば必要な最小限のもののみを作成しました。
2.開発者ごとに1〜2個のテストベンチをセットアップする
このアプローチにより、開発者は1つのタスクを表示し、2番目のタスクを実行できますが、この構成では他のタスクを見ることができません。 また、開発者がテストベンチを別のタスクに切り替えると混乱が生じます。
3.テストサーバーで、URLの生成と処理のルールを変更します
たとえば、 http：// test.local /（task-number）/（host）/（uri）という原則に従って、プロジェクト内のすべてのリンクを作成します。
そのようなオプションがありましたが、多くのリファクタリングが必要でしたので、常識ではそのルートに行くことができませんでした。 しかし、これは、この方法が他の人には機能しないという意味ではありません。
4.すべてのタスクに仮想
つまり、ホストとパスは常に同じであり、目的のタスクのコード、データベース、およびその他のサービスは独自のものです。 テストの観点から、これはおそらく理想的なオプションです。
私たちの場合、データベース、静的変数などとともに、コードの本格的なインスタンスが1つあります。 -これは数十ギガバイトのデータです。 このようなインスタンスをゼロから1回作成すると、かなり時間がかかります。 さらに、現在のすべてのタスクには1テラバイト以上のデータが必要です。 しかし、最も重要なことは、この場合、完了したタスクへのリンクを単に提供して顧客に結果を表示するだけでは十分ではないことです。 事前に起動する必要がありますが、このようなオプションは私たちにとっては便利ではないようでした。
5.仮想ホストを使用する
apache2にはUseCanonicalNameおよびVirtualDocumentRoot（ ドキュメントへのリンク ）パラメーターがあります。 これらを使用すると、ホストのサブドメインをドックパスの一部として使用できます。 apache2を再起動せずに、プロジェクトのルートとこれすべて。 実際、これらのパラメーターのおかげで、ホスト上の+ uriインスタンスへのパスを指定して、必要な答えを得ることができます。
私たちの選択
その結果、仮想ホストのオプションを選択し、次のアドレス形式を定義しました： http：//（task-number）。 （サイト識別子）。 test.local /（uri） 。（site-identifier）は次の形式の値を取ることができます：
•ru-この場合、メインサイトを.ruゾーンに表示する必要があることを理解しています
•com-ゾーン.comのメインサイト
•test.ru-.ruゾーンのメインサイトのサブドメインテスト
•data.export.com-.comゾーンのメインサイトのdata.exportのサブドメイン
メインサイトの概念がないプロジェクトには、次のルールが適用されます。
•example.com-この場合、example.comサイトを表示する必要があることを理解しています
•テスト。 example.comは、テストのサブドメインです。 example.com
•data.export。 example.comは、data.exportのサブドメインです。 example.com
•など
その結果、ブラウザーでアドレスを入力することにより： http：//task-1234.example.com.test.local/some/page/？SomeParams = value、サーバーがtask-1234タスクコードブランチ、サイトハンドラーから応答を返すことが明確にわかります。 example.com/some/page/?someParams=value。
すべてが意図したとおりに機能するためには、次のようにドックへのパスを修正する必要がありました。
/data/projects/projectName/branches/(task-number)/application/public
そして、私たちのルールに従って、プロジェクトをトレーニングしてホスト名を決定します。
機能のうち、ファイルパスの大文字と小文字が重要なシステムでは、（タスク番号）と（サイト識別子）を小文字にする必要があることに注意できます。
Apache2テストサイトの構成例：
<VirtualHost *:80> UseCanonicalName Off VirtualDocumentRoot /data/projects/projectName/branches/%1/application/public ServerName test.local ServerAlias *.test.local Options -Indexes CustomLog /dev/null combined </VirtualHost>
自動展開
最終的には、必要なコードブランチをリポジトリに作成し、テストサーバーでローカルインスタンスを数分で解凍して構成する自動展開用のスクリプトが作成されましたが、これは別のトピックです。ここではこれについて一般的な用語で説明します。展開の自動化は、さまざまな手段（bashスクリプト、phing、antなど）で実行できます。
この方法は、プロジェクトのインスタンスを上げるために実行しなければならないコマンドのシーケンスを書き留めることから成ります。 ほとんどのWebプロジェクトでは、次のようになります。
1.タスク番号を要求します（またはブランチ名をパラメーターとして取得します）。
2.リポジトリにブランチを作成します（作成されていない場合）。
3.ブランチ用のフォルダーを作成します（そうでない場合）。
4.コードをチェックアウトします。
5.必要なフォルダー/ファイルへの書き込み許可を構成します。
6.プロジェクト構成を構成します。
7.必要なシンボリックリンクを配置します。
8.（他のプロジェクト固有のアクションを実行します）;
9.プロジェクトの初期化スクリプトを実行します。
10.必要に応じて、テストを実行してすべてが正常であることを確認します。
だから
サーバーとしてapache2を使用できるプロジェクトでは、この記事で説明されている方法を使用して、仮想ホストを介してサイトの正しいバージョンを簡単に特定できます。この記事で説明されていない各ブランチのテストサイトを準備する他の方法を知っている場合は、コメントでそれらについて書いてください。これはすべての読者に非常に役立つと思います