4

私の会社は、不動産機関向けのWebアプリケーションを構築しています。最初は従来のASPでコーディングされており、.NETに段階的に移行しています。基本的に、カスタムWindowsサービス/dllと混合されたバックエンドDBを備えたWebサイトです。.NETアプリのかなりの標準。

私の過去の会社では、従来のソフトウェア設計のライフサイクルがありました。製品のリリースを作成しました。リリースすると、すべてのお客様が同じコードを受け取りました。製品要件は、エンジニアリングチームによってフィルタリングされ、ローカルのステージング環境でテストするためにQAに送信されてから、本番環境にプッシュされました。

この会社には、複数の顧客向けに複数のバージョンの製品があります。基本的に、顧客Aはリリース1.5、顧客Bは1.6、顧客Cは2.0になります。これを行うのは、アプリケーションを使用する機関が、ユーザーに影響を与える変更について厳しい要件を定めているためです。顧客がリリース1.5で問題がなければ、リリース2.0には最新の機能がすべて備わっていても、顧客はそこにとどまります。新しい「機能」は実際に混乱を引き起こしてユーザーベースを傷つけるため、顧客は実際にアップグレードを押し戻します。

このタイプのライフサイクルをサポートすることは、小さい場合は問題ありませんが、数十または数百の顧客に成長するにつれて、サポートチームは言うまでもなく、DEV、DBA、QAに負担がかかります。現在、要件が発生したときに更新できる1週間に6〜8サイトしかスケジュールできない状況にあります。これにより、他のサイトが2〜4か月待機して、サイトのマイナーな更新が行われるようにする必要があります。すぐに注意を払う必要のある本番環境の問題やバグは、事態をさらに悪化させます。更新を受信するようにすでにスケジュールされているサイトは、時間を作るために優先順位を下げる必要があるためです。

申し訳ありませんが、これは非常に長いですが、どんな助けでもありがたいです。早い段階でいくつかの変更を加えて、リリーススケジュールを改善します。ありがとう！

4

3 に答える 3

3

結局のところ、私はまったく同じ環境で作業しています。システムのセットアップ方法は次のとおりです。

  1. 各クライアントには独自のデータベースがあります。事実上、マルチテナントソリューションについて話し合っています。1つのデータベースからルールへのすべてに利点がありますが、クライアントを移動する場合、クライアントが独自のシステムをホストする場合、またはバージョン間でスキーマに違いがある場合（これは一般的です）に問題が発生します。この問題に対する他の唯一のアプローチは、単一のデータベースを使用することですが、スキーマ名（ClientA.Table1、ClientB.Table1 ...など）でセグメント化します。

  2. 単一のコードベースを使用します。仮想ディレクトリを使用して、クライアントが使用しているコードのバージョンを指し示します。同じビルド上のすべてのクライアントが同じビットを指しています。ただし、実際には複数のバージョンが出ている可能性があります。したがって、1つのクライアントが1.0.0.0を指し、別のクライアントが1.0.1.1を指している可能性があります。

  3. 誰かを更新したいときは、その仮想ディレクトリを要求されたリリースバージョンにポイントします。物理フォルダーには、完全なバージョン名（1.0.3.4など）に基づいて名前が付けられます。このアプリケーションは、予期するデータベースバージョンと現在のデータベースバージョンとの間の不一致を検出するように設計されています。違いがある場合は、管理者がデータベーススキーマを更新できるページにリダイレクトされます。すべてのデータベースの変更はスクリプト化されており、適切な順序で実行されるように設計されています。バージョン番号の3番目のオクテットを使用して、データベースのバージョンを示します。したがって、1.0.1.1は、データベーススキーマが1.0.0.0から変更されたことを示します。

  4. 発生する可能性のある質問は、「なぜ仮想ディレクトリを使用するのか」です。これは、開発に関するコアルールになります。アプリケーションコードにクライアント固有のデータや設定を含めることはできません。具体的には、アプリケーションフォルダのルートから下にあるものはクライアント固有のものにすることはできません。では、接続文字列はどうですか？これが、仮想ディレクトリを使用する理由です。仮想設定は次のようになります。

clientsite (or vdir)
    /appname_vdir

クライアントサイトのルートフォルダには、接続文字列など、データベース駆動型ではないクライアント固有の設定を含むweb.configファイルが含まれています。新しいバージョンのフォルダを指定する場合/appname_vdir、接続文字列やその他のクライアント固有のデータの更新について心配する必要はありません。これを困難にしているのは、すべてのクライアントが同じ方法でその変更を望んでいるかどうかに照らして、すべての変更が評価されていることです。そうでない場合は、その変更を無効にする（またはインストールしない）手段が必要です。

理想的には、クライアントを更新バージョンにポイントしてデータベース更新を実行するプロセスを自動化または制御するツールを構築できるため、できるだけ多くのクライアントをホストする必要があります。

ある時点で、新しいバージョンが利用可能になったことを管理者に通知できるメカニズムを構築する予定です。それらがホスト環境にある場合、更新には適切な仮想ディレクトリパスの変更が含まれます。彼らが自分自身をホストしている場合、それはビットをダウンロードしてからパス変更を行う手段を提供します。その部分はまだ構築する時間がありません。さらに、サポート担当者がユーザーを更新し、使用しているバージョンを判別できるようにする管理ツールを構築することもできます。

于 2010-11-17T01:24:42.300 に答える
0

アプリケーションの更新と展開を自動化することを考えましたか。バージョンに関係なく、アプリケーションをパッケージ化する標準化された方法を思い付くことができれば、Nolio ASAP（http://www.noliosoft.com）などのツールを使用して自動化するのは非常に簡単です。これにより、バージョンごと、さらにはアカウントごとに展開プロセスを作成でき、展開ごとの入力として差異を入力できる「ほぼ同じ」展開が可能になります。

于 2010-12-07T12:42:11.757 に答える
0

私の見方では、2つの選択肢があります。

  • すべてのバージョンを自分でホストし、クライアントが使用する必要があるバージョンをインテリジェントに区別します
  • クライアントにアプリケーション自体をホストさせる

自分でホスティングする

私はあなたがこのようにそれを行うことができると思っています：

  • 現在使用されているすべての異なるバージョンをインストールします
  • ドメインが1つある場合、各クライアントはそのサブドメインを取得します。クライアントABCはabc.mydomain.comなどにログインします。
  • リダイレクトまたはURL書き換えメカニズムを使用して、製品の適切なバージョンにサイレントにリダイレクトします
  • クライアントがアップグレードしたい場合は、データを製品の新しいインスタンスに移行し、サブドメインの書き換えルールを変更します

各クライアントが独自のデータベースを使用しているのか、マルチテナントアプローチを採用しているのかなど、セットアップについてあまり詳しくないため、ここでは少し詳しく説明していません。それらはすべて、製品の個別のインストールを使用していますか、それとも同じインストール済みインスタンスを使用していて、異なるデータを取得しているだけですか？

クライアントホスティング

これは、管理が比較的簡単です。アプリケーションのASP.NET部分をMSIインストーラーにパッケージ化でき、仮想ディレクトリやアプリプールなどの作成はすべてMSI内から実行できます。次に、DBGhostなどのデータベースアップグレードツールを使用してデータベースをパッケージ化できます。これにより、テンプレート（ソース）データベースが取得され、ターゲットと比較され、ターゲットをソースと一致させるために必要なDDLが生成されます。VS2010のバージョンの1つに含まれているこのためのツールもあることを理解していますが、私はそれを使用しておらず、コメントすることはできません。

開発スタッフは、サポートチームに使いやすい方法で更新を提供することにより、アップグレードの多くの問題を軽減するのに役立ちます。可能な場合はMSIパッケージを使用してください。可能な場合は、産業強度データベースの作成/生成ツールを使用してください。何らかの理由でデータベースアップグレードツールを使用できない場合は、データベースアップグレードが適切にスクリプト化されていることを確認してください（つまり、オブジェクトが存在する場合は、alter else create）。必要に応じて、従う必要のあるアップグレードパスを適用します。クライアントが1.6から2.0にジャンプする場合は、最初に1.8を通過する必要があります。これにより、アップグレードがよりきめ細かく、予測可能になり、管理が容易になります（1.6のアップグレードスクリプトを維持します）。 ->1.8および1.8->2.0、1.6->2.0の場合は必要ありません）。

これで十分に考えることができると思います。詳細がある場合は、投稿を編集して追加してください。

于 2010-11-17T01:03:19.557 に答える