BizTalk アプリケーションのバージョン管理は、2 つのバージョンの BizTalk ソリューションをサイド バイ サイドで実行する必要がある場合、または BizTalk アプリケーションのダウンタイムを使用して新しいバージョンを展開できない場合に問題になる可能性があります。 2 つのバージョンのソリューションを同時に実行する必要がない場合 (たとえば、実行時間の長いオーケストレーションがない場合)、サービス メンテナンス期間を利用できる場合は、古いバージョンの展開を解除し、バージョン管理戦略として新しいバージョンをデプロイできます (アセンブリのバージョン管理なし)。 これは可能なバージョン管理戦略ですが、ファイルのバージョン番号をインクリメントすることをお勧めします (BizTalk Server を実行しているコンピューターに展開されているバージョンを確認するため)。
バージョン管理を使用する場合
実行時間の長いオーケストレーションをサポートする必要がある場合、または BizTalk アプリケーションのダウンタイムなしで BizTalk アプリケーションの展開を実行する必要がある場合は、さまざまなバージョン管理シナリオに対して、堅牢なエンドツーエンドの BizTalk Server バージョン管理戦略を実装して実践する必要があります。 これには、スキーマ、マップ、パイプライン、パイプライン コンポーネント、オーケストレーション、カスタム アダプター、オーケストレーションとマップで呼び出されるカスタム クラス、ビジネス ルール、BAM など、すべての BizTalk 成果物の .NET アセンブリのバージョン管理とバージョン管理が含まれます。
スキーマのバージョン管理は、BizTalk Server パイプラインが、スキーマで定義されているターゲット名前空間とルート ノード名に基づいてメッセージのメッセージの種類を決定するという点で一意です。 詳細については、「 パイプライン コンポーネントのスキーマ解決」を参照してください。 スキーマのバージョンを設定する必要がある場合は、バージョン インジケーターがターゲット名前空間の一部である必要があります。 スキーマ バージョンの変更はソリューション全体で波及効果があるため、事前に計画する必要があります。 オーケストレーション メッセージを作成する場合は、「 BizTalk Server: 8 Tips and Tricks for Better BizTalk Programming (BizTalk プログラミングを改善するためのヒント 1: 常に複数部構成のメッセージの種類を使用する)」を検索します。 このメソッドを使用すると、スキーマをバージョン管理する際の柔軟性が向上します。
アセンブリのバージョン管理に因数分解を使用する
実行時間の長いオーケストレーション、サイド バイ サイドデプロイ、ダウンタイムなしのアップグレードをサポートする必要がある場合は、アセンブリのバージョン管理とパッケージ化の戦略を実装する必要があります。 BizTalk 成果物のアセンブリ のバージョン管理を実行するには、BizTalk ソリューション アセンブリを、BizTalk Server のバージョン管理を可能にする方法で要素化 (パッケージ化) する必要があります。 因数分解には次の 3 種類があります。
因数分解なし
すべての BizTalk 成果物は、1 つのアセンブリ内にあります。 これは理解してデプロイするのが最も簡単ですが、柔軟性は最小限です。
完全なファクタリング
各 BizTalk 成果物は、独自のアセンブリ内にあります。 これにより、最も柔軟性が高く、デプロイと理解が最も複雑になります。
最適な因子分解
BizTalk アプリケーションの詳細な分析に基づいて、"因数なし" と "フル ファクター" の間のどこかに存在します。 これにより、バージョン管理に加えて、BizTalk ホストの設計を簡単に実装できます。 これは、BizTalk 成果物間のリレーションシップを検索することによって実現されます。 常に一緒にバージョン管理される成果物は、通常、同じアセンブリに配置できます。 成果物の独立したバージョン管理が必要な場合は、異なるアセンブリに配置する必要があります。 これは、達成したい分析のレベルです。
その他のリソース
安定したバージョン管理戦略を定義して実践し、必要となる並行展開戦略を確実に提供できるようにします。 BizTalk Server アプリケーションのアップグレードとバージョン管理戦略のリソースには、次のものが含まれます。