8

PHP Web アプリケーションを作成しました。

DEV、TEST、PROD の 3 つの環境があります。

PHP Web アプリケーション コードを DEV 環境から TEST 環境、PROD 環境に移行するのに適したツール/ビジネス プラクティスは何ですか?

TEST 環境がまだ TEST データベースにのみ接続していることに気づきました。一方、PROD データベースに接続するには PROD 環境が必要です。したがって、コードはほとんど同じですが、TEST データベースではなく PROD データベースに接続するには、PROD に移動した後に TEST コードを変更する必要があります。

新しい接続が許可されず、既存のすべての接続がアイドル状態になると、Web サーバーがダウンするだけで Apache をダウンさせる人がいると聞いたことがあります。

次に、コードを手動でコピーし、PHP アプリケーションの構成ファイルを手動で更新して、PROD インスタンスも指すようにします。

大変危険なようです。

ベストプラクティスは存在しますか?

4

5 に答える 5

8

1) 構成を残りのコードから分離します。コードの残りの部分は、変更なしで 3 つの場所すべてで実行できるはずです。典型的な構成ファイルは次のようになります。

<? 
$db = "main_db"; $db_user="web1"; $db_pass = "xyz123"; 
$site ="example.com"; 
$htroot = "/var/www/prod/htdocs" 
?>

テスト環境の場合:

<? 
$db = "test_db"; $db_user="web1"; $db_pass = "xyz123"; 
$site ="test.example.com"; 
$htroot = "/var/www/test/htdocs" 
?>

コード ベースにパスワードを含む構成ファイルを含めないでください。コード ベースは、安全でない接続を介してコピーされたり、後でサード パーティのコード ホスティング サーバーに保存されたりする可能性があります (以下を参照)。また、コードのすべてのバックアップ ディスクにパスワードを保存したくない場合もあります。

単一の構成ファイルを作成し、コードが実行される環境に応じてスイッチを使用することもできます。

<? 
$site = $_SERVER["HTTP_HOST"];

if ($site == "example.com"; ) {
  $db = "main_db"; $db_user="web1"; $db_pass = "xyz123"; 
  $htroot = "/var/www/prod/htdocs";
}
if ($site == "test.example.com") { 
  $db = "test_db"; $db_user="web1"; $db_pass = "xyz123"; 
  $htroot = "/var/www/test/htdocs";
}
?>

しかし、コードベースに戻したくなるかもしれませんが、これは上記で説明したように安全性が低くなります。また、そこに配置しない場合は、3 つのファイルを更新するか、サーバーごとに 1 つの固定の場所を使用する必要があり、コードが各サーバーでファイルを見つけられるようにする必要があります。個人的には、上記のサイトごとに 1 つのファイルのソリューションを好みます。

2）すでに「バージョン」があります。現在、prod で実行されているバージョンは 1 つです。固有の名前と番号を付けます。これは二度と変更されません。コードをバックアップするとき、およびバージョンを参照するとき、またはどこかに移動するときに、そのバージョン名を使用して、バージョンの後にそれを含むサブディレクトリに名前を付けることができます。

近い将来本番環境に置くバージョンは別のバージョンであり、再度変更を加えると、これも別のバージョンになります。

経験則として、コードを移動またはエクスポートするとき、場所間で交換または交換またはアップグレードするとき、デモを作成するとき、各機能またはマイルストーンの後、および完全バックアップを行うたびに、バージョン番号を増やします。

構成ファイル (3、prod、test、および dev 用の 1 つ) はバージョンの一部ではないことに注意してください。したがって、「バージョンを移動」することはできますが、構成ファイルは移動できません。可能であれば、構成ファイルを残りのコードと一緒にツリーの外に置いてください。そうすれば、後でバージョン間を移動するときにそれらを分離して注意する必要がなくなります。config を 1 つ上のディレクトリに移動して、次のようにファイルからアクセスできます。

"include ../config.php";

3) バージョン管理システムを使用したい場合、それらは素晴らしい仕事をしますが、それに慣れるには時間がかかります。また、更新を急いでいる場合は、おそらく今すぐ使用を開始するのに適切な時期ではありません. しかし、将来的には、最新世代の分散バージョン管理システムを使用することをお勧めします。分散型とは、サーバーをセットアップする必要がなく、さらに多くの利点があることを意味します。ftp 経由で更新する必要がある場合は、bazaarと名付けます。バージョン間の相違点のみが書き込まれるため、バージョン管理システムによってバージョンの交換が非常に高速になることに注意してください。Bazaarにはコミュニティとドキュメントがあり、簡単に始められます。また、最新の商用ホスティング サイトがあるGitもあります。http://github.com。コードをオンラインで表示し、バージョン間で比較することができます。また、コード作成者が 1 人しかいない場合でも、役立つ機能が他にもたくさんありますが、グループではさらに優れています。システム間の選択は容易ではありません。時代遅れの CVS はお勧めできません。また、SVN は最新世代の分散バージョン管理システムではありません。特別な理由がない限り、SVN を使用することはお勧めしません。また、すべてのサブディレクトリが特別なサブディレクトリで汚染されるため、煩わしい場合があります。それに慣れていて、すでにコードを書いている人にとっては問題ありませんが、初心者にとってはそうではないと思います。

分散型およびオープン ソースのバージョン管理システムには、 MercurialとDarcsもあります。Mercurial には、コラボレーションとオンライン コード ビューのための優れた商用サイトもあります ( http://bitbucket.org )。

4) バージョン管理システムを使用しない限り、シンボリックリンクを使用するのはどうですか?

サーバー src/versions/ のどこかにディレクトリを作成し、そこに名前付きバージョンを配置し、それぞれを独自のサブディレクトリに配置できます。バージョンを追加するだけです（既存のバージョンは変更されないため、変更すると新しいバージョンになります）

src/versions/v001/ src/versions/v002/ src/versions/v003/ または使用する命名スキームを指定できます。

ここにトリックがあります： /var/www/prod/htdocs は src/versions/v001/ へのシンボリックリンクです

v002 にアップグレードする場合は、次の操作を行うだけです。

  • シャットダウンアパッチ
  • 古いシンボリック リンク /var/www/prod/htdocs を削除します (この時点で、Apache Webroot はなくなりました!)
  • src/versions/v002 へのリンクである新しいシンボリックリンク /var/www/prod/htdocs を作成します
  • アパッチを起動

パラメータを使用してこのスクリプトを作成し、次のように呼び出すこともできます。

upgrade-web prod 002

これにより、ギャップがさらに短くなります。

新しいバージョンに本番環境でエラーがあり、元に戻らなければならないことがわかった場合、「フォールバック」を行う必要がある場合があります。これは簡単です（古いディレクトリを削除しないため、Apacheを停止し、シンボリックリンクを削除して、以前の場所、この場合は src/versions/v001 に再作成するだけです）

また、test と dev が同じサーバー上にある場合は、もちろん同じディレクトリをシンボリック リンクすることもできるため、移動やコピーの対象はありません。

5) シンボリックリンクなしで手動で行う場合、コピーではなく移動してみませんか?

(ファイルがまだ同じサーバー上にない場合は、それらを近くのどこかにコピーしてから移行を開始できるため、サーバーを長時間停止する必要はありません)

プロジェクトのルート レベルに複数のディレクトリがある場合は、一度に 1 つずつ移動できます。構成ファイルを移動しないでください。または、それらを元に戻すための戦略を見つけます。ワークフローは次のようになります。

  • アパッチを止める
  • 構成ファイルを除く、ルート レベルのすべての現在の prod ディレクトリとファイルを移動します。
  • 構成ファイルを除くすべての新しい prod ディレクトリとファイルをルート レベルに移動します。
  • アパッチを起動

6) 完璧な個々のファイルとディレクトリのレイアウトと完璧なワークフローを見つけてみてください。これには多少の時間と検討が必要かもしれませんが、それは報われます。最善の解決策が見つかるまで、紙の上でそれを行います。これは、コードをリファクタリングしてサーバー構成ファイルを変更する必要があることを意味する可能性がありますが、将来的には、管理とアップグレードを行う方が楽になります. 私の経験から、このステップはそれほど長く待たないでください。あなたのレイアウトは、アップグレードを簡単かつ安全にする必要があります。アップグレードは特別なことではなく、日常的なものであり、安全かつ簡単に行う必要があります。

7) サーバーおよびワークステーション環境に名前を付ける場合 (サーバーのオペレーティング システムは Linux だと思いますが、それはホスト サーバーまたはルート サーバーですか? ftp アクセスまたはシェル (ssh) アクセス、または sftp を持っていますか? どこで開発していますか? 、windows マシン、または mac で?) コピーと移動を行うツールに名前を付けることができます。また興味深い: テスト サーバーと開発サーバーは同じマシンですか? そうでない場合、それらはどのように接続されていますか? そうでない場合は、3 方向転送を行います (ローカル ワークステーションにコピーしてからサーバーにコピーします)。

8) ファイルのパーミッションについて考えてみましょう。ファイルを移動またはコピーすると、ファイルのアクセス許可が変更される可能性があり、アプリケーションがそれらの一部に依存している場合は、確認して変更する方法があるはずです。例: 一部のアプリケーションでは、アップロードされたファイル、セッション ファイル、またはテンプレート キャッシュを配置する書き込み可能なディレクトリが必要です。他のアプリケーションでは、セキュリティのために一部のファイルへの書き込みを許可していません。

于 2010-04-29T15:30:25.180 に答える
3

構成ファイルを使用して、接続先のデータベースを決定します。つまり、DEV 構成ファイル、TEST 構成ファイル、PROD 構成ファイルがあります。これは一般的に、コストがかかりイライラする間違いを避けるための最良の方法です。

于 2009-11-02T22:45:43.673 に答える
3

実際、サーバーをシャットダウンせずに TEST 環境を奇跡的に PROD に移行する理由がわかりません。TEST プロダクションは、テスト目的であると想定されています。実際に運用サーバーでテストしている場合でも、それを停止し (apache をシャットダウン)、メイン構成ファイルの 1 行を変更します。これは、使用するマイナー構成ファイルのセットを決定するものです)、再度起動します (apache を起動します)。これを完了するのに 1 ～ 3 分もかからず、1 日に 12 回もしないので、問題ありません。

于 2009-11-03T16:05:02.760 に答える
1

  1. コードをリビジョン管理システムに入れます (私は Subversion (svn) を好みます)。これにより、DEV、TEST、および PROD 環境の同期を簡単に維持できます。変更したファイルを追跡する必要はありません。DEV での変更に満足したら、変更を svn にコミットし、TEST で "svn update" を実行し、最終的に PROD サーバーでテストした後に実行します。ほとんどの Linux ホスティング プロバイダーには svn クライアントがインストールされているか、自分でインストールできます。

  2. 1 つのファイルの名前を手動で変更し、他の 2 つのファイルを削除する必要があるため、サイトごとに異なるバージョンの構成ファイルを用意するのは好きではありません。DEV、TEST、および PROD 構成を同じ構成ファイルに含めることを好みます。構成ファイルでは、ホスト名またはリクエスト URL をチェックして、コードが実行されているサーバーを特定します。次に、現在コードを実行しているサーバーに基づいて構成設定をロードする「if」または「switch」ステートメントを使用できます。

  3. サーバー間でデータベース構造を同期する必要がある場合もあります。この目的で sqlyog を使用します。2 つのデータベース構造を比較し、それらを同期するための SQL を準備するデータベース構造同期ツールが組み込まれています。

于 2009-11-03T06:51:56.407 に答える
0

更新をライブにプッシュするとき、Apache を再起動する必要はあまりありません。これは、トラフィックの多いサイト (1 か月あたり 100 万未満のページ描画) がないことの副作用である可能性があります。

開発/QA のさまざまな段階に対応する 3 つのブランチがあります: アルファ (最先端ですが、非開発者やテスターも閲覧可能)、ベータ (特定のリリース、最終 QA フェーズのために多少凍結)、ライブ (本番)。

あるブランチから別のブランチに移行するには、たとえばアルファとベータの間でマージを実行し、そのマージをコミットします。次に、開発マシンの SVN からブランチを更新する展開スクリプトを実行し、コード Web サーバーをベータ ドキュメント ルートに rsync します。

他の人がすでに述べたように、各ブランチには、環境の違いに対応するための適切な設定を含む独自の構成ファイルを含めることができます。

大規模なプロジェクト/リリースの SVN で少しトラウマになる可能性があるブランチ マージ プロセスをスムーズにするために、git への移行を進めています。

于 2010-04-29T16:08:08.223 に答える