3

複数の BizTalk 2006 アプリケーション サーバーがあり、それらのプロジェクトのバージョンの同期を維持することはほとんど不可能です。MSI パッケージを展開し、それらをインポートし、GAC 内のファイルを照合し、いくつかのレジストリの変更を展開するという面倒なプロセスです。1 つの手順を実行しなかった場合、または誰かが DLL の更新されたコピーを 1 つのサーバーに直接展開し、別のサーバーには展開しなかった場合、何もありません。簡単な言い方。

他の人は、2 つのサーバー間のソフトウェアのコピーが同じバージョンであることをどのように保証しますか?

背景:

私たちの環境には、2 つの (クラスター化されていない) BizTalk フロント エンド サーバーと、別のデータベース バックエンドがあります。最近まで、両方のフロントエンドを構成していましたが、トラブルシューティングのために 2 番目のサーバーでホスト インスタンスが停止していました。それらは数か月間無効になっており、その間にいくつかの更新されたコードを展開しています.

今朝、GAC のフォルダーと、デプロイされたプロジェクトの DLL のローカル ディスク コピーを保持するフォルダー (両方のサーバーの C:\OurProject\) でフォルダーの差分を作成しましたが、すべてが一致しました - 同じファイル サイズ、同じタイムスタンプ。しかし、2 番目のサービス セットをオンにすると、Server2 が古いバージョンのプロジェクト DLL を使用していることが明らかになりました。次に処理された 3 つのファイルのうち、2 つは正常な結果で、1 つは明らかに古くなっています。

動脈瘤を避けるのを手伝ってください。

4

2 に答える 2

3

調べたいと思うかもしれないことの 1 つは、BizTalk 展開フレームワークです。

現在、BizTalk 2009 を使用して新しい環境を構築しています。私は、SubVersion からのソースのエクスポート、BTSTask を使用したアセンブリの構築と配置を処理する一連の MSBuild スクリプトから始めました。

もちろん、BTSTask には多くの機能 (アプリケーションの開始/停止) がありませんが、少なくとも BizTalk 2006 にはBTSControlがあります。

于 2010-04-08T20:54:16.367 に答える
2

Dev/Stage/Prod のバインド ファイルを含む MSI が最終的な最終エンドである自動ビルド スクリプトを使用します。リリースされたすべてのバインディング ファイルは共有に保存され、手動で BizTalk サーバーを読み込むために使用されます。最初にアプリが停止され、両方のサーバーで MSI が実行され、次に MSI がインポートされます。インポート中に、バインディングと出来上がりの環境を指定します。同期が失われるという問題はありませんでした。

そのため、最新の MSI をすべて取得し、違いのあるサーバーで再実行することをお勧めします。それ以外の場合は、反復可能なロード プロセスを手動で作成するプロセスを配置してみてください。

于 2010-04-09T16:06:52.570 に答える