現在、サーバーへのサイトのロールアウトを管理してから、サイトをデモ/アカウント/ライブの「モード」に切り替える方法は、少し危険であり、プロセス全体を改善したいと考えています.
自動展開ツールだけでなく、サーバーの構造も見直してきました。自動展開に関する質問は別の投稿に譲ります。ここでは、人々が運用サーバーでコードを整理する方法に興味があります。
現在、データ ドライブには「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 は簡単に維持できます... リストは続きます!
コード編成とロールアウト管理の方法は何ですか?