1. Install BTDF using ‘DeploymentFrameworkForBizTalkV5_7.msi’ file on the Dev machine. You will need to restart Visual Studio 2015 after the installation.
2. Open a solution in Visual Studio and right click on the solution file to add BTDF project.
3. As you soon as you click Ok, you will be asked the type of artifacts to be included in the deployment. The Deployment.btdfproj will be created based on the options selected on this pop-up.
4. Few things to remember here:
a. The *.btdfproj file is not recognized by Visual Studio as a project file. So, you will need to add the ‘btdfproj’ files manually to the Solution folder.
b. The BTDF project will create a ‘Deployment’ folder, which should be included in the solution along with other files in the folder.
5. Once the Deployment folder is added to the solution, open the ‘SettingsFileGenerator.xml’, and edit the Settings File name for each of the environments. This file can be copied to a local machine and edited in XML as well. The reason to edit the settings file name is the BTDF Deploy tasks in TFS Release definitions expect the settings file to follow naming convention as ‘<environment>_Settings.xml’ (For e.g.,Dev_Settings.xml, Test_Settings.xml, Prod_Settings.xml). The Settings File is used to store environment specific settings, which can be used to generate Binding File for specific environments.
6. You can see the type of artifacts has been included for deployment in ‘Deployment.btdfproj’. If there is a need to include or exclude any particular type of artifact from deployment, the ‘Deployment.btdfproj’ can be edited.
7. As per the solution name, the name of the MSI to be created, the BizTalk application name & referenced can be edited/added to ‘Deployment.btdfproj’. Once these properties are set, the actual artifact name & location will be specified in the ‘ItemGroup’. The details on how to include different artifacts and the syntax to be used are mentioned at Deployment Framework for BizTalk Server V5.0. Please note the relative path of the assemblies has to be included, so the assemblies included for the solution should have path within the acceptable limit of 256 characters.
8. After ‘Deployment.btdfproj’, the ‘PortBindingsMaster.xml’ file should be modified. This file is just like a binding file for BizTalk application. You can put the placeholder on the fields to be used for environment specific values like IP address, Folder name, URL etc. These values are pulled from ‘SettingsFileGenerator.xml’ and replaced in Environment specific binding files during the deployment.
9. After editing these files, you can build the ‘Deployment.btdfproj’ from Tools->Deployment Framework for BizTalk->Build Server Deploy MSI in Visual Studio.
This will create an MSI file which will be used for Deployment on TFS Build Server and other BizTalk environments. To deploy on the local server, click on Tools->Deployment Framework for BizTalk->Deploy BizTalk Solution.
10. Go to chrome and browse to TFS URL, in this example it is ‘http://<TFSServer>:8080/tfs/<teamproject>/_build ‘, click on New to create a new build definition. Select the Visual Studio template and click Next. Please note this build definition is to build a complete solution and to publish artifacts from the solution for the releases.
Keep the default options for now. The continuous integration checkbox can be checked later to allow builds for every check-in.
Remove the Nuget restore, Test Assemblies, Publish Symbol path build steps, as they are not relevant to the solution. The test assemblies can be included at a later point to have Bizunit test cases executed for every map. Add a new build step after Build Solution step, select MSBuild from Task Catalog and click Add & Close. This MSBuild task is required to build the BTDF project. The build definition will now have four steps as shown in an image below. For Visual Studio Build step, provide the TFS path of solution that needs to be built & deployed. Select the Visual Studio version as ‘Visual Studio 2015’. The Advanced & Control options default values should remain unchanged.
Before configuring other steps, it is important to specify the variables & repositories for the build definition. The repositories are nothing but a TFS server path which has to be explicitly mapped to every folder outside the solution directory. For e.g., if we are using Assemblies folder from which DLLs are referred in the projects of the solution, then the TFS server path of Assemblies should be specified in Repository. This will ensure the solution has everything it needs to compile on a TFS Build Server.
Similarly, if there are any variables to be used in build definition, it can be specified along with the initial value. This build definition will need to copy files to a file share. Also, specifying a file path in build definition results in failure. Therefore, a ‘BuildDropShare’ variable was created and a file share value was specified.
The MSBuild step should specify the project extension to be searched in downloaded code. Please note it is the TFS Build Server where TFS build will happen, not the local server. So the local paths in the entire process should align with the Build Server directories. The MSBuild step can have a relative path or the TFS path of the project to be built. In the arguments, specify the following value:
/nologo /t:Installer /clp:DisableMPLogging /p:Configuration=$(BuildConfiguration);OutDir=”$(build.binariesdirectory)\\”
The Copy Files build step searched the build binaries directory and copies the contents matching the characters mentioned in the step to Target Staging folder.
The Publish Build Artifacts step will the contents from staging directory to the specified File share for Release definition to pick up.
Save the build definition and queue a new build on specific source versions like changeset or label to test it. If the build fails, download the logs and look for the errors.
Once the build definition is successful, we can focus on creating the release definition. The process is similar to build definition but with different tasks/steps.
Click on Releases tab, click on the plus ‘+’ sign & select ‘Create release definition’. Select a template with an empty definition. The reason empty definition is required because none of the other definitions has even a single step that we could use for deployment of BizTalk artifacts in an on-premises server.
Keep the default options on the pop-up. You can uncheck ‘Continuous Deployment’ if you do not wish to trigger release for every build.
Click on Add Tasks and add BTDF Undeploy, MSI Uninstall, MSI Install & BTDF Deploy tasks in the specified order. This is to ensure that for every previous run, the Application is undeployed & uninstalled before the updated artifacts are deployed & installed for the application.
For the BTDF Undeploy task, mention the name of the application. In the first run, this task may not execute because the application may not exist in BizTalk.
The MSI Uninstall task will need the name of the MSI, i.e. Product name, this is specified in Deployment.btdfproj and the version next to it is a Product version. It is advised that the product version in this task should always match the installed version on the build server, this can be seen in Add/Remove programs. The product version can be updated in Deployment.btdfproj for future releases.
The MSI Install task needs the path of the MSI that Build definition had published. Since we used a file share to publish/drop the artifacts, the MSI path is mentioned as \\DEV-EDM-DP\BTSDeployments\$(Build.DefinitionName)\$(Build.BuildNumber)\drop\*.msi and then the Product name or name of the BizTalk application to be installed.
The Deploy task just requires the Application Name and the environment name to use the environment settings file like ‘Dev_settings.xml’.
And finally, the Window Machine File copy task to copy the MSI to other environments for deployment. This task needs the path of the source file i.e. MSI, the machine IPs where MSI needs to be copied for deployment, Admin credentials and the path on the destination server(s). If multiple server IPs are specified, then the path on each server should be alike or UNC path should be accessible on all servers.
In the artifacts tab, there should be a link to Build definition, which specifies the sources available for deployment.
Once the release definition is working as expected, the trigger to enable continuous deployment should be enabled.
You can test the release definition by triggering a build definition or by clicking on plus sign & selecting Release provided there is an artifact published by build definition for Release definition to work. The logs can be viewed on Release Definitions page. It is advised that all the logs for each task are checked to see if there are any errors. Sometimes when the task appears in green, the log has error information as shown in below example.
Please note the build server may not have the same set of pre-requisites, 3rd party assemblies, applications, Hosts, Adapters & other settings required for the BizTalk application, which is installed or available on DEV/QA servers. Therefore, it is recommended that the build server should have all pre-requisites required for the successful installation of BizTalk Applications. Once all the pre-requisites are met, the Release definition will complete successfully.
Login to build server to check if Application is created and bindings are imported. You can choose to start the BizTalk application after deployment by setting ‘True’ value in Deployment.btdfproj for StartApplicationOnDeploy.
Log in to the server to which you want to deploy the BizTalk application. Navigate to the path specified in Windows Machine File copy task in Release definition to verify if MSI is copied.
Just one folder level up, you can extract the PowerShell scripts copied from BizTalk BTDF multi-server deployment automation with the PowerShell script.
Open the command prompt in Administrator mode, change directory to the folder where PowerShell scripts are copied, type ‘InitiateDeployment.bat’ & hit enter to begin the installation of BizTalk Application. You will be prompted to enter Admin user credentials and click Cancel when prompted to choose an existing application.
You will be prompted to choose environment settings file for the server.
Once the application is installed, the command prompt will display a success message and BizTalk Admin console & Add/remove programs console will have newly installed application.
Please note the MSI installed through BTDF isn’t same as the one extracted from BizTalk Admin console. To un-deploy, go to Start->All Programs->Application Name <Product Version> -> Undeploy and also uninstall the application from Add/remove programs.
If there is a need for redeployment, un-deploy & uninstall the application, rebuild the MSI, copy it to the server where the application has to be installed at the MSI folder where PowerShell scripts are copied.