ASP.NETの展開/保守のベストプラクティス
私はWeb開発業界に5年ほどいますが、常にオープンソース環境で働いています。ほとんどがApache、mysql、およびphpで、Rubyが少しあり、バージョン管理にgitを使用しています。しかし最近、開発が完全にC＃ASP.NET MVCである仕事を始めました。
言語などはかなり簡単に習得できましたが、私のチームの他のメンバー（MS開発の経験が私よりもはるかに多い）は、最終的なサイトの公開と展開に関して異なる考え方を持っています。特に将来の変化。
他の開発者の考え方は、いったんサイトが公開されるとそれが最終的なものになるということです。このサイトにこれ以上変更を加えることはできません。私がこれの背後にある理由を尋ねたところ、その答えは危険すぎる、時間がかかる、または難しいというものでした。
私の過去の経験から、サイトの更新は、変更されたファイルをアップロードする場合にすぎません。これは通常、少しの変更であれば非常に迅速です。または、更新中にサイトをメンテナンスモードにすることもできます。
最近MVCサイトを公開しましたが、企業から連絡があり、テキストの一部を更新して新しいPDFドキュメントへのリンクを追加しました。私のチームの他のメンバーは、サイトは現在稼働中であり、変更してはならないため、これを行うべきではないとすぐに言った。マイクロソフトの開発者に「育てられない」ことで見逃したことはありますか？
本番環境のライブWebアプリケーションに変更を加えることに対する反対の主張は何ですか？この考え方は.NET開発者に固有のものですか？
私はこの考え方を理解し、それがマイクロソフトの開発環境で正当化されるのか、それとも古い考え方なのかを理解したいと思います。
注：バージョン管理にはTFSを使用し、発行プロファイルを使用して、サイトが展開される場所を決定します（UATまたは本番）
ASP.NET MVCアプリケーションがコンパイルされます。これは、たとえばPHP Webサイトの場合のように、変更されたファイルを単にアップロードすることはできないことを意味します。これは、サイトの更新を開始すると、現在のユーザーが捨てられる（たとえば、セッションを失う）。
単にファイルを更新するだけではありません。処理する必要があります。
権限
新しいバージョンでは、サーバー上で異なる一連の権限が必要になる場合があります。
構成
新しいバージョンでは、Distributed Transaction Coordinator（MSDTC）サービスをインストールする必要がある場合や、別のSMTPサーバーを使用する場合、Active Directoryにアクセスする場合などがあります。これには、アプリケーションとサーバー自体の両方の構成の変更が含まれます。 。
依存関係
たとえば、初心者がよく遭遇する問題の1つは、古いDLLを
/bin異なる名前で新しいものを追加している間：アプリケーションは古いものを引き続き使用する場合があり、アプリケーションのコードを変更するという奇妙な状況が発生しますが、アプリケーションの動作は同じです。データ
データベーススキーマが変更され、アプリケーションがNoSQLではなく通常のSQLサーバーを使用するとどうなりますか？スキーマを変更するにはどうすればよいですか？変更中にデータを正しく保つ方法は？
アプリケーションの古いバージョンと新しいバージョンの間の移行を処理することは困難な作業です。数年前、これは問題の1つであり、アプリケーションの新しいバージョンが準備できましたが、システム管理者が展開するのに数日または数週間かかりました。 DevOpsはこの問題に対処しますが、開発者がアプリケーションをホストするシステムを（コードまたは構成を通じて）説明する必要があります。
アプリケーションが大きいほど、このタスクは複雑になります。
小さなWebアプリの場合、ソースファイルをサーバーにコピーするだけで十分です。
より大きなものについては、更新プロセスを処理する自動化プロセスと、何か問題が発生した場合のロールバックが必要です。
さらに大規模なシステムでは、新しいバージョンごとに新しいVMが作成およびデプロイされ、古いVMがリサイクルされるため、ユーザーを古いバージョンから新しいバージョンにシームレスに移行できます。
コンパイルされたアプリケーションは、単にプロセスをより早く自動化することを強制/奨励します。
テキストの一部を更新し、新しいPDF文書へのリンクを追加するよう、ビジネスから連絡がありました。私のチームの他のメンバーは、サイトが現在稼働しているため、これを行うべきではないとすぐに言った
IMO、この拒否の実際の技術的な理由はありません。 十分に自動化されていないと、タスクにエラーが発生しやすいであるため、彼らはそれを避けたいだけです。
通常、次のことが起こります。
アプリケーションが初めてデプロイされます。
チームは数時間かけて構成を調整し、機能させます。チームは3週間前に納品する予定だったので、誰もが急いで、誰も変更のメモを取っていません。
これでアプリケーションが起動して実行されます。
数週間、数ヶ月、または数年の間、一部のランダムな人々がサーバー上のいくつかのランダムなものを変更します。たとえば、データベースを別の場所に移動したり、SMTPパスワードを変更したりして、Web.configを変更しました。
今すぐ新しいバージョンを更新すると、最初のステップに戻ります。正しい構成を回復するには数日かかる場合があります。ウェブサイトは公開されているため、これは絶対に避けてください。
プロジェクトマネージャー、開発マネージャー、または他の開発者以外の誰かがいますか？
稼働後の展開は不可能であることはZEROの理にかなっています。
もちろん、これらの変更は、とりわけスケジュールを立て、コストをかけ、リソースを投入する必要がありますが、「いいえ」と言っても意味がありません。
表示されている動作の主な理由は、これらのタイプの変更がエラーを起こしやすいことです。アプリケーションを手動で更新すると、忘れられたり、同期がとれなくなったりします。 まだ部分的なパッチではなく、新しいリリースを実行できるはずです（そして簡単にできるはずです）。
ライブサイトで一部のCSSまたはテキストを変更するなどの部分的な更新により、テストのスキップ、テストまたはステージング環境が同期しなくなったり、コードをソース管理にコミットしなくなったりする可能性があります。これがコードの変更である場合、復旧計画を立てずにライブサイトを壊してしまう可能性さえあります。
.NETではコードがコンパイルされるため、ロード時間が長くなったり、ユーザーセッションが失われたりするなど、他の問題が発生する可能性があります。これらの問題は、暖かい環境へのスワッピングとプロセス外のセッション状態の使用を軽減する可能性があります。ただし、これらの種類の問題や、展開を行うたびにアプリケーションに固有のその他の問題について考えたい場合を除きます。次に、ライブWebサイトにパッチを適用することは悪い考えです。
アプリケーションのサイズが大きくなり、人々が行き来するにつれて、これは不便から深刻な問題へと移行する可能性があります。安全のため、次のようなルールに従います。ライブWebサイトを更新するには、パッチを適用するだけでなく、完全な展開である必要があります。
展開をまだ自動化していない場合（ルールに従うのが簡単かつ迅速になります）。新しい展開は通常、既存のバージョンの横で行われ、Webサイトは必要なバージョンへのポインタにすぎません（Noteデータベーススキーマにより、これは少し複雑になります）。
1.0.0 // Old version you can roll back to
2.0.0 <-- IIS points here
実際には、同様の理由で すべての展開は本当に自動化する必要があります であり、.NET以外の展開も含まれると思います。展開の自動化を開始すると、それらが一貫して高速で信頼できることを保証できます。
私は定期的に、Amazon AWS、Windows Azure、プライベートウェブサーバーにデプロイされたかなりの数のASP.NET MVCウェブサイトを再公開/再デプロイしていますが、チームがそのように大きなことを行っている理由はわかりません。
ただし、テキストやリンクの更新などのタスクがWebサイトの管理インターフェイスを介してデータベースを通じて実行されるように、Webサイトを設計する必要があります。
私の要点は、稼働中のWebサイトへの変更は問題ありませんが（開発と呼ばれます）、アプリケーションを再デプロイしてテキスト文字列を変更することは、デザインが悪いことを示している可能性があります。私は、再出版が注意なく行われることを示唆していません。