内部ビジネスアプリケーション用のWindowsインストーラーは理にかなっていますか？
この状況で一般的なことを一般的に理解して、さらに追求する意味があるかどうかを判断できるようにしています。
- インストーラーは、次のような一般的な企業環境で歓迎されますか？
- 変更管理プロセス
- 開発/ QA /本番環境
- さまざまな領域（ファイアウォール、データベース、ウィンドウなど）の指定された展開チーム。
- インストーラーを作成するのに適しているかどうかを確認するためにアプリケーションに適用できる「リトマステスト」はありますか？ *
- インストーラーはすべてのアプリケーションに1つ必要なほど単純ですか？
- インストーラーも適切なツールですか？
- インストーラーをサポートするために、開発者にWiXのようなものを学ぶことを期待することは理にかなっていますか？
- 一般に保守性が問題になります。つまり、インストーラーを作成することはニッチなスキルですか？
*
たとえば、実稼働サーバーの共有ディレクトリにある一連のwinformアプリケーションがあります。特定のグループがこのディレクトリからアプリケーションを実行できますが、実行可能ファイルを変更できるのはシステム管理者だけです。現在のデプロイプロセスでは、管理者が実行可能ファイルとライブラリを共有ディレクトリにコピー/貼り付けする必要があります。
アプリケーションは個々のユーザーのマシンにインストールされないので、これらのアプリケーションの新しいバージョンを共有ディレクトリにデプロイするためのインストーラーを作成することには意味がありますか？
編集-
ここでの回答はいくつかの確かなアドバイスを与えると感じたので、現在のプロジェクトで思いついたものを共有したいと思いました。そこでは、多数のアプリケーションを作成して個々のフォルダーに展開する必要がありました。
Webプロジェクトの_PublishedWebsitesの動作を模倣する _ PublishedApplications というNuGetパッケージを見つけました。 NuGetパッケージをプロジェクトにインストールすると、ビルドアーティファクトを出力パスの_PublishedApplicationsディレクトリにコピーするターゲットが追加されます。この動作は、コマンドラインからMSBuildを実行し、outdirプロパティを指定することでアクティブになります。
msbuild /p:Configuration=Release /p:outdir=C:\path\to\outdir MySolution.sln
これにより、次のようなディレクトリ構造が得られます。
- C：\ path\to\outdir
- _PublishedApplications\
- Project1\
dlls, exes, etc.
- Project2\
...
- Project1\
- _PublishedApplications\
そこから、さまざまな環境で抽出できるZipを作成するのはかなり簡単です。
インストーラー常には意味があります、展開に関連ファイルをいくつかのフォルダーにコピーしてEXEを実行するよりも複雑なものが必要な場合製品を適切に設定するために追加の手順が必要な場合は、2つの方法で対処できます。
- 誰かがフォローするためのリストを書き出すことができます。人間は人間であり、誰かがそれを台無しにして、あなたのプログラムが正しく実行されていないので助けを求めるように呼ばれます。
- コンピュータがフォローするリスト（インストールスクリプト）を書き出すことができます。これにより、ユーザーエラーが展開を台無しにする可能性がはるかに低くなります。
一方、実行する必要があるセットアップタスクがない場合は、zipファイルを指定します。インストーラーを実行するよりも簡単です。
ワイアットはプログラマーの帽子を脱いで、彼のITディレクターの帽子をかぶっています
これが内部の基幹業務アプリケーションである場合は、1つの環境のみを狙う必要があります-このビジネスです。私はIT部門の責任者に電話し、展開をどのように管理したいかを尋ねます。 IT部門はしばらくの間これに対処してきたため、xcopyやMSIベースのオプション、または現在のオプションなど、完全に他のオプションを強く好む可能性があります。
私はその部門が少なくともジェスチャーを評価し、彼らが既存の基幹業務アプリと問題についてあなたが理解するよりも多くのことを知っている可能性があるので、貴重な同盟国になる可能性があると付け加えます。
Windowsインストーラーアプリケーションは、Windowsを使用する環境に内部ビジネスアプリケーションをインストールするために広く使用されています。また、アプリケーションの存続期間にわたって、ユーザーのシステムから更新、パッチ適用、修復、または完全に削除する必要がある可能性が高いかどうかについても自問する必要があります。多くの場合、答えは「はい」です。この場合、適切に作成されたインストーラーがあれば、長期にわたってアプリケーションを維持するための総コストを削減できます。 Windowsインストーラーと連携するように設計された他のサービスと機能があります。たとえば、Restart ManagerとWMI、製品とパッチのインベントリ機能などです。アプリケーションがこれらの恩恵を受けることができる場合、それはインストーラーを含めるもう1つの理由です。
アプリケーションに役立つインストーラーを開発するための先行費用は長期的に見返りがあり、WiXやInstallShieldなどの適切なWindowsインストーラー作成ツールを選択することで開発費を軽減できます。
すべてのエンジニアリングの決定と同様に、状況によって異なります。
おそらく最も重要な要素は、インストールプロセスのコンシューマーが誰か、開発チームのスキルセットを理解することです。
これは社内向けなので、社内のIT部門によって展開されていると思います。彼らはおそらくコマンドシェルを知らない人ではありません。
グラフィカルインストールウィザードは、ファイルサーバーの場所やセキュリティポリシーなど、構成に関する簡単な仮定が無効になるため、外部の顧客に直接配布されるソフトウェアに役立ちます。したがって、各ユーザーが設定を選択するようにガイドする必要があります。
あなたの環境では、これはおそらく開発またはITのどちらかによって決定され、めったに変更されません。したがって、シェルスクリプトを使用してファイルを適切な場所にコピーすることをお勧めします。スクリプトは、リリースされるパッケージの一部として製品内に存在する必要があります。アプリと一緒にバージョン管理する必要もあります。
私が作業している場所では、Webアプリケーション全体がInstallShieldウィザードを介してインストールされます。InstallShieldウィザードは一連の質問をします。そのほとんどは、ファイルシステムの場所、db接続情報、その他の設定で構成ファイルに含まれる設定です。自動化するのは難しいです。コアでのWebアプリのインストールでは、いくつかのデータベースが作成されてファイルがコピーされるため、AntまたはPowershellを使用して、.sqlファイルを実行してファイルをコピーする新しいインストーラーを作成しています。
その後、誰もがそれがどのように機能するかを理解し、より効果的に維持することができます。