Feature: Add Knowledge of Inter-Application Dependency Stack

[tfabraham]

1) If application B relies on A, B has to be undeployed to redeploy A (for example B uses schemas contained in A). It would really be cool if this "stack" could be defined in BTDF. So if I'm fixing something in project A, B has to be undeployed, A has to be redeployed, then B has to be redployed. This would be a feature only for the development environment.   2) For the QA/production environment MSI install, a super-deploy of multiple MSI's in the proper order would also be very nice. Most applications that I've worked with are 5 to 25 inter-related applications with dependencies. BTDF still is very helpful. At one client, we had a spreadsheet of about 25 BT applications to deploy, and the proper order. There was still a large chance the the admins would mess up the deploy if they were not careful.

This work item was migrated from CodePlex

CodePlex work item ID: '6130' Vote count: '5'

[tfabraham]

[giuliov@3/9/2010] I addressed this with a Powershell deploy script that works at a higher-level, and I think that is a more generic approach: in my script I take care of other pieces outside the BTS applications.

[tfabraham]

[tfabraham@3/9/2010] I also believe that this belongs in a layer that exists above the individual solutions that use the Deployment Framework. A meta-script that understands the dependencies and drives all of the individual solution deploy/undeploy cycles across multiple servers. I do think that such a script can become part of the Deployment Framework package, just not a "core" component of the Framework itself.

[tfabraham]

[UnknownUser@3/11/2010]

[tfabraham]

[Rokhead@3/11/2010] I could see where this would be useful. Right now, it is a matter of the developer just "knowing" the stack, i.e. Install A, then B, then C. Uninstall in reverse, C then B, then A.

[tfabraham]

[UnknownUser@5/18/2010]

[tfabraham]

[UnknownUser@6/7/2011]

[tfabraham]

[fkuiper@8/26/2011] I've written a MsBuild script that does exactly what is in the description. It utilizes the targets 'DependsOn' attributes to maintain the stack so I've created a target for each package. Well actually I've create three targets for each package: PackageA, PacakageA_Remove and PackageA_Add. The first target is dependent on the last two: PackageA --> dependson="PackageA_Remove;PackageA_Add"

If you add PackageB that relies on PackageA you also create the same three targets, but now you add two extra target dependencies: PackageA_Remove --> dependson="PackageB_Remove" PackageB_Add --> dependson="PackageA_Add"

The cool thing is that you know let MsBuild figure out in which order your packages need to be undeployed and deployed. If you have a stack of 25 packages and you need to add a new one you don't have to rearrange you whole script (as we used to do) but let MsBuild figure it out run time... as long as you have your dependencies in place.

[tfabraham]

[UnknownUser@10/20/2011]

[tfabraham]

[charliemott@11/14/2012] This functionality will be provided within the BizTalk Administration Console in BizTalk 2013. See here: http://adventuresinsidethemessagebox.wordpress.com/2012/11/07/biztalk-2013-beta-new-features-dependency-modelling-in-the-administration-console/

[tfabraham]

[UnknownUser@2/21/2013]

[tfabraham]

[sandernefs@5/10/2013] Hi Ferdinand,

I believe you mean that you use MSBuild to figure out the dependencies and that you only need some sort of 'config' file, which would make life a lot easier.

Are you willing to share this script here as well?

Regards,

Sander

[tfabraham]

[fkuiper@5/17/2013] Hi Sander,

I unfortunately can't share the entire script here (there is to much business information in it), but I can share some highlights :)

What I've done is I've written a MSBuild target file containing 4 targets:

• Install feature
• Deploy feature
• Uninstall feature
• Undeploy feature

(a feature in this context is one BTDF-msi by the way)

The install feature target looks something like this:

<Target Name="InstallFeature">
    <Message Text="Installing '$(FeatureName)'..." />
    <!-- Install and copy MSI to install dir -->
    <Exec Command="msiexec /i &quot;$(FeatureName)-1.0.0.msi&quot; /passive" WorkingDirectory="..\Packages" />
    <CreateItem Include="..\Packages\$(FeatureName)-1.0.0.msi">
        <Output ItemName="MsiToCopy" TaskParameter="Include" />
    </CreateItem>
    <Copy SourceFiles="@(MsiToCopy)" DestinationFiles="@(MsiToCopy-&gt;'c:\Program Files (x86)\$(FeatureName) for BizTalk\%(FileName)%(Extension)')" />
</Target>

And the Deploy feature something like this:

<Target Name="DeployFeature">
    <!-- Start deployment -->
    <Exec
        Command=".\Framework\DeployTools\EnvironmentSettingsExporter.exe EnvironmentSettings\SettingsFileGenerator.xml EnvironmentSettings"
        WorkingDirectory="c:\Program Files (x86)\$(FeatureName) for BizTalk\1.0\Deployment\"
        Condition="Exists('c:\Program Files (x86)\$(FeatureName) for BizTalk\1.0\Deployment\EnvironmentSettings\SettingsFileGenerator.xml')"
        />
    <MsBuild
        Projects="c:\Program Files (x86)\$(FeatureName) for BizTalk\1.0\Deployment\$(FeatureName).Deployment.btdfproj"
        Properties="DeployBizTalkMgmtDB=$(BT_DEPLOY_MGMT_DB);Configuration=Server;SkipUndeploy=true;ENV_SETTINGS=c:\Program Files (x86)\$(FeatureName) for BizTalk\1.0\Deployment\$(ENV_SETTINGS_MASK)"
        />
</Target>

Uninstall and undeploy are very simular in setup.

Ofcourse these target in itself will not do anything. There are more scripts. One is the 'main'-project file which will import all 'features' and contain the main targets 'Deploy' and 'Undeploy'

<Import Project="Deployment.Targets" />

<Import Project="Feature.ApplicationA.config" />
<Import Project="Feature.ApplicationB.config" />

<!-- Deploy alle packages -->
<Target Name="Deploy">
    <CallTarget Targets="@(BizTalkApplication-&gt;'%(Identity)_Add')" />
</Target>

<!-- Undeploy alle packages -->
<Target Name="Undeploy">
    <CallTarget Targets="@(BizTalkApplication-&gt;'%(Identity)_Remove')" />
</Target>

Last but not least there are the "feature config's" and that's where most of the magic happens:

<ItemGroup>
   <BizTalkApplication Include="ApplicationA"/>
</ItemGroup>

<Target Name="ApplicationA_Add" DependsOnTargets="">
    <MsBuild 
        Projects="$(MSBuildProjectFile)"
        Targets="InstallFeature"
        Properties="FeatureName=ApplicationA"
        />
    <MsBuild    
        Projects="$(MSBuildProjectFile)"
        Targets="DeployFeature"
        Properties="FeatureName=ApplicationA"
        />
</Target>

<Target Name="ApplicationA_Remove" DependsOnTargets="">
    <MsBuild    
        Projects="$(MSBuildProjectFile)"
        Targets="UndeployFeature"
        Properties="FeatureName=ApplicationA"
        />
    <MsBuild    
        Projects="$(MSBuildProjectFile)"
        Targets="UninstallFeature"
        Properties="FeatureName=ApplicationA"
        />
</Target>

The config for feature B contains exactly the same as the above, but ofcourse you have to replace ApplicationA with ApplicationB. When you start the main msbuild file and call target "Deploy" all the features are installed and deployed and removed in sequence. Now for the magic to happen you can use the "DependsOn" attribute for the "ApplicationA_Add" target like this:

<Target Name="ApplicationA_Add" DependsOnTargets="ApplicationB_Add">
    ...
</Target>

Ofcourse you have to add the same dependancy to feature B when removing it, like this:

<Target Name="ApplicationB_Remove" DependsOnTargets="ApplicationA_Remove">
    ...
</Target>

With this setting ApplicationB will allway be installed and deployed BEFORE ApplicationA and ApplicationA will allways be remove BEFORE ApplicationB.

And that's how I've solved the dependancy tree problem for our 27 (or so) individual BTDF-msi's.

Hope this will be helpfull to you.

Kind Regards, Ferdinand.

[tfabraham]

[UnknownUser@10/14/2013]