Web アプリケーションの開発/テスト セットアップで、dvcs (bzr、git) を使用する場合、実際にリポジトリ ディレクトリからアプリケーションを実行するのが間違っているのはなぜですか?
私が遭遇したすべてのチームには、リポジトリのチェックアウトを別のディレクトリまたはサーバーにエクスポートする個別の展開スクリプトがありますが、その理由がまったく理解できず、「大人になった」人に「愚か」に見えないように頼むのが怖かったです...つまり、とにかく、それは本番環境ではなく開発サーバーなので...?
パスとアクセス許可が現実のものに近いランタイムを見て、エラーが現実を反映するようにするか、非標準展開に解決される奇妙な問題を実行することに時間を費やしますか?特異性？ご存知のように
または、速度を低下させますが、高品質のコードの提供には貢献しないその他の多くのことのいずれかです。
tl;dr: @Schwern が以下に述べていること。
明確にするために、問題は実際には展開方法に関するものではありません。それはまったく別の問題です。より深い原則は、@DaveEが述べた理由により、テスト環境はできるだけ本番環境に近づける必要があるということです。わずかな展開の違いにより、テストが役に立たなくなる可能性があります。
本番環境のインストールをミラーリングするのは、開発中のテストには手間がかかりすぎると考えているようです。それには2つの解決策があります。テスト環境を本番環境とは異なるものにすることは、その 1 つではありません。
まず、製品のインストールを簡単にします。これにより、手動のプロセス (ここにファイルをコピーし、これらのスクリプトを実行し、これらの権限を変更する...) が自動化されたプロセスに変わる可能性があります。または、展開が実際に行うことを削減している可能性があります。詳細が分からないとなんとも言えません。
テスト環境がない場合、開発環境は次のようになります。テスト環境であり、運用前の唯一の防衛線であるというより厳格なルールに従う必要があります。これを回避するには、テストするステージング サーバーを作成します。ステージング サーバーは、本番環境を可能な限りミラーリングするサーバーです。開発用コピーは最初にステージング サーバーにインストールされ、本番環境にプッシュされる前にテストされます。これにより、2 段階のテスト システムが得られます。正確ではない開発環境でいくつかのテストを行い、ステージング環境で一連の完全なテストを実行します。完全なテスト スイートを常に実行する必要はないため、ステージング サーバーを常に更新する必要はありません。YMMV。その後、本番環境の前にすべてが完全なインストールでテストされることを認識しながら、開発環境を手抜きして開発をスピードアップできます。
リソースがある場合、ステージング サーバーは、運用環境のすべてのハードウェアとソフトウェアの完全なミラーです。あなたはおそらくそれを持っていないので、それは仮想マシンまたは単なるサブディレクトリである可能性があります. チームの他のメンバーからの賛同を得なければ、両方とも開発マシン上に置くことができます。
インストール プロセスとステージング サーバーを自動化することは、継続的な統合テストを開始できることを意味します。これは、「コミットごとにテスト サーバーでテストを自動的に実行する」ことを意味する凝った用語です。継続的インテグレーション システムの例はJenkinsです。そうすれば、展開がどれほど複雑であっても、ロボットが処理してくれます。
最初は面倒な作業に思えるかもしれませんが、最終的にはボタンを押さなくてもテストできるようになります。
最終的に、新しいコードは、実際にプッシュする前に、本番環境にできるだけ似た環境でテストする必要があります。それを達成する方法はたくさんありますが、それは堅実なルールです。