2

現在、サーバーへのサイトのロールアウトを管理してから、サイトをデモ/アカウント/ライブの「モード」に切り替える方法は、少し危険であり、プロセス全体を改善したいと考えています.

自動展開ツールだけでなく、サーバーの構造も見直してきました。自動展開に関する質問は別の投稿に譲ります。ここでは、人々が運用サーバーでコードを整理する方法に興味があります。

現在、データ ドライブには「demo」、「acceptance」、「live」の 3 つの最上位フォルダーがあります。何かを「デモ」または「ACC」として分類するものの間にはわずかな違いがありますが、これについては触れませんが、すべての議論/あいまいさを取り除きたいと言えば十分です。

ロールアウト手順は次のとおりです。サイトが開発されたらacceptance.project-domain.com、「acceptance」フォルダーの下などの「acceptance」ホスト ヘッダーの下にロールアウトします。クライアントはサイトをレビューし、すべての接続文字列/権限などが正しいことを確認するためにテストを行います. クライアントはライブへの OK を出します。この時点で、サイトを「ライブ」フォルダーの下に完全に再展開し、ライブ ホスト ヘッダーを指定します。もちろん、この時点では、サイトは展開された状態で完全にテストされていません (ここでは単体テストについては話していません。つまり、ファイルのアクセス許可、iis の設定ミスなど)。その後、サイトを再テストする必要があります:(

このような構造は、はるかに優れていると思います。

/<customer>/<project>/<fullversion>/wwwroot

version1このようにして、新しいサイトを"acc" ホスト ヘッダーの下のフォルダーに展開できます。クライアントが OK を返したら、ヘッダーを切り替えるだけで済みます。変更要求がある場合v1.1は、受け入れヘッダーを持つことができる下に移動し、OK を取得したら、ヘッダーを交換すれば問題ありません。すすいで繰り返します。

このプロセスは、自動化された展開スクリプトの管理もはるかに簡単になります。サイトのすべてのコードを 1 つの親フォルダーの下に置くということは、アップロードのアクセス許可を 1 つのサイトに制限できることを意味します。そのため、別のサイトのコードを誤って上書きすることはありません。サーバー上にあるバージョン、プロジェクトを追跡するのがはるかに簡単になります。管理 wiki は簡単に維持できます... リストは続きます!

コード編成とロールアウト管理の方法は何ですか?

4

1 に答える 1

1

ほとんどの人は、テスト用とライブ用に別々のサーバーを使用しているため、提案した方法で動作しません。

プロジェクトからすべての構成を削除したので、テストマシンとライブマシンにまったく同じコードをデプロイでき、正しい構成が自動的に取得されます。これにより、予期しない「ライブではなくテストを指している」瞬間を防ぐことができます。

あなたのアイデアはうまくいくかもしれませんが、将来サーバーを分割することにした場合はどうなりますか(たとえば、ライブWebサイトに影響を与える可能性がある場合、サーバーに対してパフォーマンステストを正確に実行することはできません)。

于 2009-10-13T07:40:47.500 に答える