A typical BizTalk best practice is always to develop each interface under its own solution and dedicated BizTalk application. This also aligns to what BTDF (BizTalk deployment framework) built on. However, this is a tricky one in the healthcare solution since the solution usually built on a tree structure

Each node in the above diagram represents a set of business interface, in the ideal world, develop & deploy individually is the way to go. However, this poses a potential risk as what if the common referenced artifact has to change from time to time, in the real world, a full undeploy and deploy is not realistic.

An alternative solution, as suggested by a coworker is to deploy all interfaces within a single BizTalk application. BizTalk will happily accept the ‘overwrite’ flag to deploy the changes. But this is not the way BTDF is implemented. To make this work, I made a custom tool, added to the MasterBuild post event, the tool will auto discover all the BTDF projects, analysis the dependencies, merge them as well as the binding files, finally producing a super version of deployment project which will be used in the QA and production deployment.

As for the version , BTDF technic is based on side by side deployment, the client I am working with does not like to version their artifact this way as it easily get messy and hard to manage. I come up with a workaround to use the ‘label’ of BTDF project

By changing the BTDF msbuild target, I am able to have the MasterBuild output both version 1.0 (default, full build) and 1.1 (only artifacts with label ‘1.1’) MSI, this way, the change can be easily deployed without uninstalling the entire application.

On a side note, I chose to use CruiseControl instead of TFS build due to the mess to handle the post build events. The workflow is described below,

Drop me a mail if you like the sample solution. Happy deploying.