ASP.NETの展開/保守のベストプラクティス

私はWeb開発業界に5年ほどいますが、常にオープンソース環境で働いています。バージョン管理にgitを使用して、ほとんどの場合、apache、mysql、およびphpに少しルビーを追加します。しかし最近、開発が完全に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ながら、別の名前の新しいDLL を追加することです。アプリケーションは古いDLLを使用する可能性があり、これにより、アプリケーションですが、アプリケーションの動作は同じです。

• データ

  データベーススキーマが変更され、アプリケーションがNoSQLではなく通常のSQLサーバーを使用するとどうなりますか？スキーマを変更するにはどうすればよいですか？変更中にデータを正しく保つ方法は？

アプリケーションの古いバージョンと新しいバージョンの間の移行を処理することは困難な作業です。数年前、それは問題の1つであり、アプリケーションの新しいバージョンが準備できましたが、システム管理者が展開するのに数日または数週間かかりました。DevOpsはこの問題に対処しますが、開発者がアプリケーションをホストするシステムを（コードまたは構成を通じて）説明する必要があります。

アプリケーションが大きいほど、このタスクは複雑になります。

• 小さなWebアプリの場合、ソースファイルをサーバーにコピーするだけで十分です。

• より大きなものについては、更新プロセスを処理する自動化プロセスと、何か問題が発生した場合のロールバックが必要です。

• さらに大規模なシステムでは、新しいバージョンごとに新しいVMが作成およびデプロイされ、古いVMがリサイクルされるため、ユーザーを古いバージョンから新しいバージョンにシームレスに移行できます。

コンパイルされたアプリケーションは、プロセスをより早く自動化することを強制/奨励します。

一部のテキストを更新し、新しいPDFドキュメントへのリンクを追加するように、ビジネスから連絡がありました。私のチームの他のメンバーは、サイトがライブであるため、これを行うべきではないとすぐに言った

IMO、この拒否の実際の技術的な理由はありません。うまく自動化されない場合、タスクはエラーが発生しやすいため、彼らはそれを避けたいだけです。

通常、次のことが起こります。

1. アプリケーションが初めてデプロイされます。

2. チームは数時間かけて構成を調整し、機能させます。チームは3週間前に納品する予定でしたので、誰もが急いで、誰も変更のメモを取っていません。

3. これでアプリケーションが稼働しました。

4. 数週間、数か月、または数年の間、一部のランダムな人々がサーバー上のいくつかのランダムなものを変更しました。たとえば、データベースを別の場所に移動したり、SMTPパスワードを変更したりして、Web.configに変更を加えました。

今すぐ新しいバージョンを更新すると、最初のステップに戻ります。正しい構成を回復するには数日かかる場合があります。ウェブサイトは公開されているため、これは絶対に避けてください。

プロジェクトマネージャー、開発マネージャー、または他の開発者以外の誰かがいますか？

稼働後は配備できないというのは、ゼロの理にかなっています。

もちろん、これらの変更は、とりわけスケジュールを立て、コストをかけ、リソースを投入する必要がありますが、「いいえ」と言っても意味がありません。

表示されている動作の主な理由は、これらのタイプの変更がエラーを起こしやすいことです。アプリケーションを手動で更新すると、忘れられたり、同期がとれなくなったりします。あなたはまだ部分的なパッチではなく、新しいリリースを行うことができるはずです（そしてそれは簡単なはずです）。

ライブサイトで一部の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サイトへの変更は問題ありませんが（開発と呼ばれます）、アプリケーションを再デプロイしてテキスト文字列を変更することは、デザインが悪いことを示している可能性があります。私は、再公開が注意なしに行われることを示唆していません。