現在のプロジェクトには、1。本番サーバー、2。テストサーバー、3。Windowsでxamppを使用する開発者がいます。Prod-およびTestserverはUNIXによって実行されます。
他の開発者の1人は、Windowsでxamppを使用していることについて繰り返し不満を言っています。彼は、開発目的でテスト環境にvサーバーを作成する必要があると言っています（開発者ごとに1つのvサーバーかもしれませんが、よくわかりません）。私には、これはひどく間違っていると感じます。しかし、リモートの開発サーバーに接続する必要があるなどの明白な理由を除いて、その理由を実際に説明することはできません。
これが私のやり方です。4つの段階があります。
1）ローカルサーバー。ここでは、独自の変更や機能ブランチなどに取り組むことができます。作業を行い、マシンで機能することを確認してから、開発ブランチにプルするように要求します。
2）開発サーバー。これは、開発ブランチにあるものすべてのカーボンコピーであり、コードがa）実際の環境でどのように機能し、b）他の人のコードで遊んでいるかを確認する手段として意図されています。
3）QAを行う必要がある「テストサーバー」。このサーバーの設定は、本番環境の設定にできるだけ近づける必要があります。そして、あなたが取り組んできたすべてのバグ修正、機能、および改善を調べて、解決するか、報告することができます。
4）生産。コードがここに到達するまでに、コードは安定していて、すぐに使用できるようになっているはずです。これは、クライアントにとっての「最終製品」である必要があります（まだバグを修正している/メンテナンスを行っている場合でも）
環境がすべて可能な限り同じように構成されている場合、環境間を移動するときに（開発からライブへのテスト）、驚きを感じる可能性は低くなります。
XAMPPを介してWindowsでPHPを実行すると、Unix/Linuxベースのサーバーで実行する場合と比較して動作に微妙な違いが生じます。これらに対処しなければならないことは、開発に不必要なオーバーヘッドを追加し、バグがすぐに発見されないリスクを高めます。
オフィスで仮想サーバーを実行すると、Windowsデスクトップを引き続き使用できますが、コードを記述しているときでも、実稼働サーバーの正確なシミュレーションでコードを実行できます。また、PHPのアップグレードやバックアップの設定などが必要な場合に、多くの個別のPCを管理する必要がないため、システム管理者の作業を簡素化できます。
不便さに関しては、「samba」を使用する場合、これはそれほど大きな問題ではありません。開発サーバー上のファイルはWindowsファイル共有としてアクセスできるため、自分のマシンにある場合と同じように編集を続けます。 。サーバーに直接（SSH経由で）接続する必要があるのは、Apache構成を変更し、変更を有効にするためにデーモンを再起動/再ロードする必要がある場合のみです。
専用の開発環境を管理する利点の1つは、開発サーバーを定期的に再デプロイする自動ビルドプロセスを実装できることです。これにより、開発サイクルの早い段階で互換性のない変更を発見する可能性が高くなります。