BizTalk Server: Automation Deployment with Azure DevOps – Deploying the Project

Following Sandros last post on BizTalk Server: Automation Deployment with Azure DevOps – Create a build agent, we’re going to show how to create the deployment steps, by creating the Pipeline and Release Pipeline, using a few DevOps tasks.

The standard BizTalk Deployment task does a decent job in deploying the application, but it doesn’t handle changing tokens or registering DLLs in GAC.

To deploy in multiple machines or to change your Bindings according to your environment, you have to make your file dynamic. This means, replacing your connections with variables.

Let’s start with the basic:

Creating the project and installing it in DEV

As always, it’s better to first create the DevOps repository and clone it in your machine.

Having this created, you need to get your project working and have a Deployment Project as well. This will contain the needed DLLs and Binding files pointers to your BTS project. This will also contain the Application name to be deployed and some other configurations.

You will see that you can set the Biztalk Assemblies path as well as other Assemblies, Pre and Post processing scripts and the Deployment Sequence. This is one of the most important steps, because, as you know, it does matter in which order you deploy your BT Assemblies.

When referencing your BT projects, do make sure that the Application Project is using the same framework version as your other projects. If it’s not the same version, it will not be able to copy the DLLs to the referenced Path and will not build successfully.

Building this project will generate a ZIP file that contains all that is needed. You can try to publish it directly, after configuring the application.

The bindings file that is created with the project is just an empty template, so you’ll want to deploy your application in your Dev Environment and create those bindings. It will make a difference if you export your application bindings when it’s started and when it’s stopped, so keep that in mind.

For this example, I’m going to export the bindings with the Application fully stopped.

Your standard Bindings export will carry the ports and URIs/connections straight from the Admin console. Through a little magic, we will configure these values to be dynamic and it’s super easy.

Making your Bindings dynamic for deployment

Now you’ve exported the bindings and you want to make it ready for DevOps and to accept multiple configurations.

From my example, you can see that the ReceiveLocation and ReceivePort names are static. If we tokenize this, you can call it whatever you want, therefore reducing the risk of colliding with other existing ports in your end systems.

So, keeping in mind the desired token, I’m going to replace these values, ReceiveLocation address included, with a variable and token identifier. With a few magic touches, we end up with something like this:

And that’s it. Of course, this is a very small and simple example, but even with a goliath project, it will still be the same pattern. You find what you want to make dynamic, tokenize it, save and upload your changes to your Repo.

Building your Pipeline and Release Pipeline

Now you have your source code in your Repository, your bindings ready for dynamic changes and you want to deploy it.

You will need to set up your build Pipeline before you can get your Release ready, so get to work.

The Pipeline itself doesn’t need to be too complicated, you just need to build your Solution, with or without the OutPath argument (I found that setting this would make my life easier in some projects) and publish the drop.

With your drop created, your Release pipeline needs the following tasks:

  • Extract Files – to unzip your file
  • Replace Tokens (a great extension by Guillaume Rouchon, more info here)
  • Archive Files – to zip it back
  • BizTalk Server Application Deployment – I recommend this, but you can do it with PowerShell

Extracting your file contents is straight forward, you just need to select your zip in your drop contents and a destination folder. Keep in mind that you will need to know where it lands, to zip it back.

Replacing the Tokens is just as before, you select the *.XML mask or point directly to your bindings and select the Token that it should be looking for. Remember, that the variables you define are case sensitive. You can also use a Variable Group, it is a great way of knowing your environment specific variables or common variables that your might have.

Once this is done, you can proceed to recreate the Zip file and it’s contents. The destination folder you’ve selected when Unzipping will now be the Root folder you are pointing to.

Remember to tick out the “Prepend root folder name to archive paths” option. If you keep this selected, your file will end up with a structure like “Zip / bindings” instead of just “bindings” and the deployment will fail, because it’s not the expected folder structure. Also, tick the “Replace existing archive” option, else you will create a copy and deploy the original version instead.

And for the final step, the Deployment Task. I chose to use the standard task instead of PowerShell, because I didn’t want to handle scripts at this point.

Select the Zip package and set the operation to Create. From what I’ve found out, this will Upsert your application, while Update will not create the app if it doesn’t exist.

And this is what you need. If you’ve set everything properly, your Release Pipeline will deploy your Application to your Server and get it up and running, with the parameters you’ve set in your bindings file.

It took a while to understand how this process worked but in the end, it turned out to be very simple and all it took was to apply the same concept we already used with the ARM deployment for Azure resources.

Happy coding!

Author: Pedro Almeida

Pedro Almeida is a Senior Integration Developer at Devscope, working with Logic Apps, BizTalk, and other related products. Although he started his career as a Dynamics CRM Consultant, Integrations quickly caught his eyes and has made it his primary area of interest and work. Since then, Pedro has worked with customers from very different areas, from Retail to Banking to Governmental Services and others.

9 thoughts on “BizTalk Server: Automation Deployment with Azure DevOps – Deploying the Project”

  1. This is a process that replaces BTDF. I am facing one issue using this process, How can I read a variable from the DevOps release pipeline in BizTalk orchestration. Earlier in BTDF we used SSOSettingsFileReader.ReadString to read a variable in orchestration. Is any option available in this new way of deployment.

    1. Hello Parveen,

      For this you’d need to read directly from SSO, grab the value to a environment variable in DevOps and then you’d replace it in the Bindings file or the Orchestration file.

      There’s no Out-of-the-box task or PowerShell command for this, so you’d need to write a custom helper and execute this in the pipeline as if you’d be running a console app.

      Sandros’ tool for SSO Application Configuration CLI Tool already contains the necessary code to read from the repository.

      We’re already working on another change to this tool and provide some other functionalities, including registering a SSO application from DevOps without extra work.

  2. Hello Pedro,
    Thanks for the response. I want to read the environment variable from devops release pipeline. I know we can accesss these variables in binding file of application project using $(‘variable’), but is there a way to access the environment variable inside orchestration? I don’t want to use sso now. Instead want to access variable directly from release pipeline.

    1. You can’t access the release pipeline after you’ve executed it. It’s not how that works.

      You use the pipeline to deploy the contents and then you need to use SSO to get your values in runtime.

  3. I’m following the Microsoft official tutorial in order to configure BizTalk 2020 with DevOps, and the release pipeline is deploying the MSI “properly” but at the end I’m getting the error message: “No mapping was made between account names and security identifiers.”. Any suggestion? I’m developing in my personal Hyper V, Windows server 2016, I really would do appreciate any help.

    1. Hello Josue,

      From what you describe, it appears that the user you’ve selected is not available in the environment. Taking the answer from a colleague:

      “Most likely you have a role defined in database that contains users or user groups not available in deployment environment. For example you have user group Domain1\UserGroup1 specified in role, but you are trying to deploy this database in environment where Domain1 is not available. To fix this error simply replace users or user groups with values that are correct in deployment domain.”

      1. Thanks for your response Pedro,

        I uninstalled SQL and BizTalk, so I cleaned up all, but I’m still facing the same problem, the Azure Pipeline service is running under my administrator account, is the same account I use for SQL and BizTalk.

        “he user you’ve selected is not available in the environment” <- you meant the user that runs the Azure Pipeline service?

        Thanks a lot in advance!

  4. I forgot to mention, I’m working in the same machine, I developed my BizTalk project in VS 2019, and want to deploy the project in the same VM.

    Thanks in advance.

  5. Finally, I did it works, seems like there is something wrong in my VM hosted in Hyper V, I installed a Dev BizTalk environment in my local pc, and it worked, I replicate the same scenario, and it worked like a charm! thanks, Pedro!

Leave a Reply

Your email address will not be published. Required fields are marked *

BizTalk360
BizTalk Server

Over 500+ customers across
30+ countries depend on BizTalk360

Learn More
Serverless360
Azure

Manage and monitor serverless
components effortlessly

Learn More
Atomicscope
Business Users

Monitor your Business Activity in iPaaS
or Hybrid integration solutions

Learn More

Back to Top