As a consultant, my role is to give advice, work on projects and help out customers. As I don’t want to be the Single Point of Truth, my approach is to transfer my knowledge in workshops/sessions with the internal developers or people who I think should know about certain technologies.
In the past i’ve used the BizTalk Deployment Framework (BTDF) quite often. I have experienced that getting to know the concepts and working with it, is a developers choice, however this choice impacts the way administrators need to work.
This post summarizes my experiences and contains some of the slides i used when having workshops on the BTDF, with some caveats, and thinks to think about.
First of all, why? Why would i need a new framework, what is wrong with the way i do my deployments right now? Nothing, however, in certain cases, you might run into some limitations, in the slide below some pros and cons of applying the classic deployment vs using the BTDF.
As we can see, the main advantages are having a consistent approach, automated deployments and a way to perform multi server deployments. However, keep in mind, to achieve this, we need to learn a complex framework, where you can make mistakes, which will not give you all the pros! So learning it, before applying it is crucial, and as always, it is not a golden hammer!
Below an overview of important features
Note: The reason for deviating from a standard product and using the out-of-the-box features by choosing a tool, framework should be that it add features that are not possible in the standard product.
My #1 requirement for a tool, framework, utility is the support provided. My experiences with the BTDF are just amazing. I’ve posted a feature suggestion to include some of the VS.Net menu items as startmenu items upon deployment, and a couple of days later it was in the new 5.1 release! (authors: Thomas F. Abraham / Scott Colestock)
Before applying it, after having in depth knowledge of the problems you can overcome by the framework. Ensure that the people involved in the project/integration platform are familiar with the BTDF, know about the advantages, agree on the usage, are willing to use it. The BTDF works different, so unless you are the dev/admin you need to agree that this is the framework for you!
In stead of deploying your solution and creating an MSI by exporting this application from the BizTalk Administration console. The BTDF will generate an MSI based on a .target file which contains steps such as packaging the bindings, settings, dll’s etc. The BTDF MSI in different as it packages the BTDF along with it. So when deploying on a machine, you are actually deploying using the BTDF in a different mode.
So design time we are working from visual studio, we generate the MSI (or it is generated by the BuildServer) and deployment it ont he target machine.
Assuming we have a BizTalk project with artefacts, we can add a new BTDF project after following the steps mentioned below;
Right….nothing is shown? Correct, the BTDF project is not a known type in VS.Net. We need to manually add the artefacts used.
There are 3 concepts extremely important, on which we need to focus, but which is something you should learn before making any decisions in your project.
- SettingsFile generator
This is the ‘master’ configuration file, this contains all the settings used, possibly for your different environment. So when following an DTAP strategy, this possible contains all the settings for each environment.
Caveat: this means your environments must be static, known in advance, and should not change often, as this file needs to be administrated and is per solution/application!
You can implement the BTDF in various ways, one is to have a Masterbinding (binding with macros), which is used to generate environment spefiic bindings;
Masterbinding (macros ABC) + settingsfile with environment values ABC = binding with replaced values for ABC.
In this post, i am not going to use Masterbindings, but alternative bindings, similar to ‘classic bindings with BizTalk’.
MSBuild is a xml configuration based framework used by the BTDF. The project file created, is basically a configuration file for MSBuild tasks.
The Deployment.btdfproj works with Propertygroups
You can override, configure custom properties, in the example below i am overwriting the output path so that all my build files are generated on a specified locations.
The ItemGroup contains the Artefact specific configuration
So as stated, i’m not using Masterbindings, as i don’t like to use macros etc within my team. I would like them to export a binding file, and add it to the project. We have this flexibility too! Follow the steps mentioned below;
2 Step redeployment
The last thing to mention, is one of the features that can explain why an automated framework is good. Let’s consider an application, which contains a ‘Common’ application.
Our deployment options are limited with the ‘classic’ approach
How does the BTDF solution helps us? We have 2 steps
Removes the application from BizTalk
Removes the artefacts from the machine + configuration.
In our case…..we only need to really do step #2 for the Common. Replace it and deploy, we do not need to Uninstall everything (which already worked). So now we can, we can Undeploy all the applications from BizTalk, and leave the dll’s components, configuration on the system.
For the common we need to
Step #1: Undeploy all applications
Step #2: Uninstall the application CommonStep #4: Redeploy all other applications
Step #3: Deploy the application Common
The advantage of the BTDF is that we can script this, so we can actually perform a much more complex deployment and do it in a consistent way, as described in the slide below
Start learning the BTDF
So, how to start learning the BTDF? Follow the lab ‘Helloworld’ with the steps mentioned below;
Note: I cannot provide the original slides, hopefully these prints suffice..