ASP.netを運用Webサーバーに展開する適切な方法

Question

これが、ASP.net（主にイントラネット）のWebサイト\プログラム\アプリケーションを社内の運用Webサーバーに展開するように指示された方法です。

私の知る限り、私はそうあるべきです：

どちらが優れたデプロイ方法ですか？

これら2つのデプロイ方法の長所と短所は何ですか？

これを行うための標準的な方法（貧しい人または安価な方法）はありますか？

Harry Ninh · Accepted Answer

私の苦痛な経験から、展開プロセスの多くが手動で行われているほど、より大きな問題が発生します。そして、現在のステップは両方とも、手作業による多大な労力が必要です。これが私の推奨事項です：

1。VS Publish機能を最低限使用してください

自動デプロイメントプロセスを実現するための最初のステップは、ご存じのとおり、Visual Studioの発行機能を使用することです。 XML変換の適切な設定により、この機能はweb.config（およびその他のXMLベースの構成ファイル）で発生する必要のある変更を処理します。

理想的には、運用サーバーにアクセスできる場合は、公開を運用サーバーのWebサイトにターゲティングできます。これにより、コピー/貼り付けが行われます。それ以外の場合は、システム内の分離されたフォルダをターゲットにします（ソースコードフォルダと間違えないようにしてください）。

2。継続的インテグレーション（CI）と継続的展開（CD）を採用

これは、主に単一の開発者によって保守されている小さなプロジェクトにとってはやり過ぎかもしれません。しかし、プロジェクトがモンスターに進化した場合、CI/CDが適しています。 CI/CDの使用を開始するための指標は次のとおりです。

プロジェクトとそれに取り組んでいるチームが大きくなり、新しい変更が導入されるたびにWebサイトのすべての面を文字どおり手動でテストできない=>自動テストが必要であり、誰かが変更をコミットするたびにテストを行う必要がある。
これで、デプロイする複数の環境があります（開発、ステージング、UAT、本番、名前を付ける）。それぞれのパブリッシュプロファイルを作成することは引き続き可能ですが、特定の環境にいつデプロイするかを知ることは難しくなります（たとえば、すべてのテストが他の環境に合格し、上司（別名、顧客）が本番環境にのみデプロイする場合） UATに満足）。
デプロイメントをロールバックする機能が必要です。かっこいいですね。 CDを使用すると、ボタンを1回クリックするだけで、最新の展開で何かが南下する時間を文字どおり節約できます。
機密性の高い構成データがソース管理にチェックインされないようにしたい（たとえば、接続文字列を運用DBに新しく採用したジュニア開発者に公開したくない場合）。 VS Publish + XML変換を使用したワークフローでは、これを実現するのが難しくなります。

最初に使用できるCI/CDツールはたくさんありますが、一部は無料です。現在、CIのTeamCityとCDのOctopus Deployに満足しています（どちらも小規模チームは無料です）。