Logic App Standard CI/CD from zero to hero whitepaper

Logic App Standard CI/CD from zero to hero whitepaper

Continuous integration/continuous delivery (CI/CD) pipelines are a practice focused on improving software delivery using a DevOps approach.?

A CI/CD pipeline may sound like overhead, but it isn’t. It’s essentially a runnable specification of the steps that any developer needs to perform to deliver a new software product version. In the absence of an automated pipeline, Engineers would still need to perform these steps manually and, therefore, be far less productive.

This is a must to have when deploying resources to Azure! Especially for non-development environments.

In this whitepaper, I will address and explain in a detailed way a complete guide for automating the implementation of Logic Apps Standard using Azure DevOps Pipelines.

I will explain in detail all the basic things you have to know, from the creation of a Logic App Standard on Visual Studio Code to everything you need to create and configure inside DevOps to archive the implementation of the CI/CD process.

What’s in store for you?

This whitepaper will give you a detailed understanding of the following:

  • An introduction to:
    • What are Continuous Integration (CI) and Continuous Deployment (CD)?
    • What are CI/CD Pipelines?
    • What is Azure DevOps?
  • Create an organization or project collection in Azure DevOps
  • Create a project in Azure DevOps
  • Building your Logic App Standard from scratch
    • Publish your code from Visual Studio Code
  • A step-by-step approach to building Azure Pipelines
  • A step-by-step approach to building Azure Release Pipelines

Where can I download it

You can download the whitepaper here:

I hope you enjoy reading this paper and any comments or suggestions are welcome.

Azure Function App CI/CD from Zero to Hero whitepaper

Azure Function App CI/CD from Zero to Hero whitepaper

Continuous Integration and Continuous Deployment (CI/CD) is a practice that has become an essential aspect of Azure development. Although it is possible to execute each of the CI/CD pipeline steps manually, the actual value can be achieved only through automation.

And to improve software delivery using CI/CD pipelines, either a DevOps or a Site Reliability Engineering (SRE) approach is highly recommended.

In this whitepaper, I will address and explain how you can implement CI/CD oriented to Azure Function Apps using Azure DevOps Pipelines.

I will explain in detail all the basic things you have to know, from the creation of an Azure Function on Visual Studio 2022 to everything you need to create and configure inside DevOps to archive the implementation of the CI/CD process using Azure Functions.

What’s in store for you?

This whitepaper will give you a detailed understanding of the following:

  • An introduction to:
    • What are Continuous Integration (CI) and Continuous Deployment (CD)?
    • What are CI/CD Pipelines?
    • What is Azure DevOps?
  • Create an organization or project collection in Azure DevOps
  • Create a project in Azure DevOps
  • Building your Azure Function from scratch
    • Publish your code from Visual Studio
  • A step-by-step approach to building Azure Pipelines
  • A step-by-step approach to building Azure Release Pipelines

Where can I download it

You can download the whitepaper here:

I hope you enjoy reading this paper and any comments or suggestions are welcome.

BizTalk Server CI/CD from zero to hero whitepaper

BizTalk Server CI/CD from zero to hero whitepaper

Historically, deploying BizTalk Server solutions across environments is or can be a complicated process depending on how complex is your solution. There are many ways to deploy BizTalk artifacts for example:

  • Importing them as part of an application by using the Deployment Wizard (from a .msi file), importing them using BTSTask.exe – this is the default way to deploy across environments.
    • You can replace and use allow BTSTask, and PowerShell scripts.
  • Or deploy them from Visual Studio – this is the default way to deploy to your development environment.

Throughout the years, the BizTalk Server Community created an open-source deployment framework called Deployment Framework for BizTalk (BTDF) – https://github.com/BTDF/DeploymentFramework. The Deployment Framework for BizTalk is an easy-to-use toolkit for deploying and configuring your BizTalk solutions. In reality, BTDF is an MSBuild project with custom MSBuild tasks and it can be customizable according to customer BizTalk project needs, it is also extensible. This framework brings new capabilities and advantages to deploying BizTalk Server solutions, but it also has limitations or disadvantages.

Microsoft has introduced automated deployment of BizTalk Applications in BizTalk Server 2016 Feature Packs using Azure DevOps (previously called Visual Studio Team Services – VSTS). In BizTalk Server 2016 Feature Pack 1, automatic deployment and application lifecycle management (ALM) experience was introduced. The automatic deployment process has been improved with the release of BizTalk Server 2016 Feature Pack 2. These features were only available on the Enterprise edition of BizTalk Server 2016.

BizTalk Server 2020 brings all these functionalities out-of-the-box across all editions: Enterprise, Standard, Development, or Branch.

To accomplish this, we need basically 3 main steps:

  • BizTalk Server: Add a BizTalk Server Application project to your Visual Studio solution.
  • DevOps: Create a build agent.
  • DevOps: Create a Build and release Azure Pipeline.

This whitepaper will address and explain how you can implement CI/CD oriented to BizTalk Server using Azure DevOps Pipelines.

In this whitepaper, Pedro Almeida and I will provide a detailed introduction to CI/CD. It teaches how to Create a project collection. Learn how to prepare the visual studio for projects end to end. A well-defined pipeline. Helps you understand how to save development time by thinking long-term since it is a low-cost, high-return scenario.

What’s in store for you?

This whitepaper will give you a detailed understanding of the following:

  • An introduction to:
    • What is a CI/CD Pipeline?
    • What are CI/CD Pipelines?
    • What is Azure DevOps?
  • Create an organization or project collection in Azure DevOps
  • Create a project in Azure DevOps
  • Preparing your Visual Studio BizTalk Server project for CI/CD
    • Creating a BizTalk Server Deployment Project
      • Add the application project
      • Making your Bindings dynamic for deployment
      • Configure the BizTalkServerInventory JSON template
    • Publish your code
  • Create a Personal Access Token
    • Install the Build Agent
  • Building your Azure Pipeline
    • Building the Pipeline
    • Building the Release Pipeline
    • Defining the Variables
  • Using SSO Application Configuration with CI/CD

Where I can download it

You can download the whitepaper here:

I hope you enjoy reading this paper and any comments or suggestions are welcome.

Logic App CI/CD from zero to hero whitepaper

Logic App CI/CD from zero to hero whitepaper

Continuous Integration and Continuous Deployment (CI/CD) is a practice that has become an essential aspect of Azure development. Although it is possible to execute each of the CI/CD pipeline steps manually, the actual value can be achieved only through automation.

And to improve software delivery using CI/CD pipelines, either a DevOps or a Site Reliability Engineering (SRE) approach is highly recommended.

In this whitepaper, Pedro Almeida and I will demonstrate how you can use Azure DevOps Pipelines to implement CI/CD based on Logic Apps (consumption).

We will explain it all in detail, from creating a project in Azure DevOps, and provisioning a Logic App Consumption to configuring the built Logic App for CI/CD.

What’s in store for you?

This whitepaper will give you a detailed understanding of the following:

  • An introduction to:
    • What is a CI/CD Pipeline?
    • What are CI/CD Pipelines?
    • What is Azure DevOps?
  • Create an organization or project collection in Azure DevOps
  • Create a project in Azure DevOps
  • Building a Logic App (Consumption) from scratch
  • Setting up the Visual Studio Logic App (Consumption) project for CI/CD
  • A step-by-step approach to building Azure Pipelines

Where I can download it

You can download the whitepaper here:

I hope you enjoy reading this paper and any comments or suggestions are welcome.

Microsoft Integration and Azure Stencils Pack for Visio: New version available (v7.3.1)

Microsoft Integration and Azure Stencils Pack for Visio: New version available (v7.3.1)

The full 7.3 version is complete with the release of v.7.3.1. This was a massive work of adding new shapes of new services that appear on Azure and changing the existing one with the new version of the shapes. Work is done and I hope you enjoy it!

What’s new in this version?

This is the list of changes and additions present in this release:

  • New shapes on MIS Azure Stencils, MIS Azure Additional or Support Stencils, MIS Developer Stencils, and MIS Security and Governance packages: add a considerable amount of new shapes of new services that appear on Azure has both changing the existing one with their new layout.
  • Move old versions of the shape layout to MIS Azure Old Versions package.
  • New shapes on MIS AI and Machine Learning Stencils: several new shapes add it to this package with several Cognitive Services.
  • New shapes on Microsoft Integration Stencils: some new shapes add it to this package describing Schemas, Maps, Aggrements, Partners, Assemblies and so on.
  • Lock the aspect ratio of the new stencil icons: This was a requested made that can be very handly to protects against accidental resizing with another shape aspect.
  • SVG files: new SVG files added.

Microsoft Integration, Azure, Power Platform, Office 365 and much more Stencils Pack

Microsoft Integration, Azure, Power Platform, Office 365 and much more Stencils Pack it’s a Visio package that contains fully resizable Visio shapes (symbols/icons) that will help you to visually represent On-premise, Cloud or Hybrid Integration and Enterprise architectures scenarios (BizTalk Server, API Management, Logic Apps, Service Bus, Event Hub…), solutions diagrams and features or systems that use Microsoft Azure and related cloud and on-premises technologies in Visio 2016/2013:

  • BizTalk Server
  • Microsoft Azure
    • Integration
      • Integration Service Environments (ISE)
      • Logic Apps and Azure App Service in general (API Apps, Web Apps, and Mobile Apps)
      • Azure API Management
      • Messaging: Event Hubs, Event Grid, Service Bus, …
    • Azure IoT and Docker
    • AI, Machine Learning, Stream Analytics, Data Factory, Data Pipelines
    • SQL Server, DocumentDB, CosmosDB, MySQL, …
    • and so on
  • Microsoft Power Platform
    • Microsoft Flow
    • PowerApps
    • Power BI
  • Office365, SharePoint,…
  • DevOps and PowerShell
  • Security and Governance
  • And much more…
  • … and now non-related Microsoft technologies like:
    • SAP Stencils
Microsoft Integration (Azure and much more) Stencils Pack

The Microsoft Integration Stencils Pack is composed of 28 files:

  • Microsoft Integration Stencils
  • MIS Additional or Support Stencils
  • MIS AI and Machine Learning Stencils
  • MIS Apps and Systems Logo Stencils
  • MIS Azure Additional or Support Stencils
  • MIS Azure Black and Gray
  • MIS Azure Old Versions
  • MIS Azure Stencils
  • MIS Black and Cyan
  • MIS Buildings Stencils
  • MIS Databases and Analytics Stencils
  • MIS Deprecated Stencils
  • MIS Developer Stencils
  • MIS Devices Stencils
  • MIS Files and Message Types Stencils
  • MIS Generic Stencils
  • MIS Infrastructure and Networking Stencils
  • MIS Integration Fun
  • MIS Integration Patterns Stencils
  • MIS IoT Stencils
  • MIS Office, Office 365 and Dynamics 365
  • MIS Power BI Stencils
  • MIS Power Platform Stencils
  • MIS SAP Stencils
  • MIS Security and Governance
  • MIS Servers (Hexagonal) Stencils
  • MIS Users and Roles Stencils
  • MIS API Connectors
  • Organisational Stencils

That you can use and resize without losing quality, in particular, the new shapes.

Download

You can download Microsoft Integration, Azure, BAPI, Office 365 and much more Stencils Pack for Visio from GitHub Here:

The post Microsoft Integration and Azure Stencils Pack for Visio: New version available (v7.3.1) appeared first on SANDRO PEREIRA BIZTALK BLOG.

Microsoft Integration and Azure Stencils Pack for Visio: New version available (v7.3.0)

Microsoft Integration and Azure Stencils Pack for Visio: New version available (v7.3.0)

The full 7.3.0 version is not yet complete, but I decided to release it in small pieces instead of taking a long time to make all the planned changes and being the Azure part that will require the most work.

What’s new in this version?

This is the list of changes and additions present in this release:

  • New shapes on MIS: Office, Office 365 and Dynamics 365 package: add some new Dynamic 365 shapes like Dataverse, SCM Warehousing, Project Timesheet, Return To School orReturn To Work, and several new Office/Office 365 shapes.
  • Remove API Connectors shapes from MIS: Power Platform package: there goal was to simplify this package and migrate that stencils to a dedicated package, since there are more then 600 connectors. Also these connectores are common to Power Automate, Power Apps and Logic Apps.
  • Create a new package MIS: API Connectors: This package will provide stencils to all connectors currently provided for Microsoft Power Automate, Microsoft Power Apps, and Azure Logic Apps.
  • Lock the aspect ratio of the new stencil icons: This was a requested made that can be very handly to protects against accidental resizing with another shape aspect.
  • SVG files: new SVG files added.

Microsoft Integration, Azure, Power Platform, Office 365 and much more Stencils Pack

Microsoft Integration, Azure, Power Platform, Office 365 and much more Stencils Pack it’s a Visio package that contains fully resizable Visio shapes (symbols/icons) that will help you to visually represent On-premise, Cloud or Hybrid Integration and Enterprise architectures scenarios (BizTalk Server, API Management, Logic Apps, Service Bus, Event Hub…), solutions diagrams and features or systems that use Microsoft Azure and related cloud and on-premises technologies in Visio 2016/2013:

  • BizTalk Server
  • Microsoft Azure
    • Integration
      • Integration Service Environments (ISE)
      • Logic Apps and Azure App Service in general (API Apps, Web Apps, and Mobile Apps)
      • Azure API Management
      • Messaging: Event Hubs, Event Grid, Service Bus, …
    • Azure IoT and Docker
    • AI, Machine Learning, Stream Analytics, Data Factory, Data Pipelines
    • SQL Server, DocumentDB, CosmosDB, MySQL, …
    • and so on
  • Microsoft Power Platform
    • Microsoft Flow
    • PowerApps
    • Power BI
  • Office365, SharePoint,…
  • DevOps and PowerShell
  • Security and Governance
  • And much more…
  • … and now non-related Microsoft technologies like:
    • SAP Stencils
Microsoft Integration (Azure and much more) Stencils Pack

The Microsoft Integration Stencils Pack is composed of 27 files:

  • Microsoft Integration Stencils
  • MIS Additional or Support Stencils
  • MIS AI and Machine Learning Stencils
  • MIS Apps and Systems Logo Stencils
  • MIS Azure Additional or Support Stencils
  • MIS Azure Black and Gray
  • MIS Azure Old Versions
  • MIS Azure Stencils
  • MIS Black and Cyan
  • MIS Buildings Stencils
  • MIS Databases and Analytics Stencils
  • MIS Deprecated Stencils
  • MIS Developer Stencils
  • MIS Devices Stencils
  • MIS Files and Message Types Stencils
  • MIS Generic Stencils
  • MIS Infrastructure and Networking Stencils
  • MIS Integration Fun
  • MIS Integration Patterns Stencils
  • MIS IoT Stencils
  • MIS Office, Office 365 and Dynamics 365
  • MIS Power BI Stencils
  • MIS Power Platform Stencils
  • MIS SAP Stencils
  • MIS Security and Governance
  • MIS Servers (Hexagonal) Stencils
  • MIS Users and Roles Stencils
  • Organisational Stencils

That you can use and resize without losing quality, in particular, the new shapes.

Download

You can download Microsoft Integration, Azure, BAPI, Office 365 and much more Stencils Pack for Visio from GitHub Here:

The post Microsoft Integration and Azure Stencils Pack for Visio: New version available (v7.3.0) appeared first on SANDRO PEREIRA BIZTALK BLOG.

DevOps – Multi environment variables/ groups

DevOps – Multi environment variables/ groups

This is a topic that has been asked to me a few times, making me wonder how hard it actually was. Working with this nearly every day makes us assume some things are very easy, but not everyone has this insight.

So, exactly do we set variables for different environments and how does it work when we want to replace tokens?

Variables for different environments

Having multiple environments creates the need to have different values assigned to your variables, because, for example, that Test Webservice won’t work in PROD and you definitely don’t want to use that PROD file share and delete files in your DEV/Test environment.

Using Pipeline Variables helps you to set different values to different Stages.

This is extremely helpful because, even though you have to duplicate/triplicate variables, you won’t need to worry about the incorrect value going to the wrong stage. Also, having the Scope set to Release, it will affect all stages.

So, it’s a win-win situation.

But! It’s only valid for this Release Pipeline in specific. If you have another Release and some variables are common, you have to re-do everything… all, over, again.

Send in the Variable Groups!

Variable Groups

The Variable Groups are containers for variables that can be used in multiple Releases and Pipelines. Think of it as a common class in your project that you can reference anywhere.

You can define the Groups and their variables in the Library. Inside the group, you can set all the variables you need, and add to it any time as well, and assign the values right away.

Keep in mind that this is thought of as a static group, it’s not supposed to change often.

If you change a variable value or add a new one, it will not be considered in the already created releases. If anything changes in here, you will need to create new releases (not the pipelines) and redeploy them. When you create the release, it takes a snapshot of the values and uses them as they are. Thus the need to create a new one to get those new values.

After linking the group to the Release, you will see that you can also set a Scope. This works exactly like the pipeline variables, they will only be used in that specific Stage and nowhere else.

Also, when expanded, you can see the values that are set for that group.

Now, how does the Token Replacement task works with this?

Replace Tokens

This task, our savior (yes, I like it very very much), comes to our rescue once again.

I’ve explained before how to use it and how it works.

But for this post, I’ll explain again. The task searches in the folders/files you’ve defined and tries to match the token that you’re setting in the definition with the one in the file(s). As the token is found, it uses a string.Replace function to inject the values in the files.

It will scour the Variables for a match and take the value to insert in the file.

But how does this link with the Variable Groups?

Well, at runtime, DevOps does a magical thing and sees the groups you’ve defined for a Stage as variables. So technically, it’s as if you’ve defined all the variables in one place and not in groups.

Pretty sweet, right?

So, the Replace Tokens will use all those variables and will try to replace them in your files. You don’t have to define the group or anything, it will just see the whole picture.

Hope this helps you with your automations and deployments.

Happy coding!

The post DevOps – Multi environment variables/ groups appeared first on SANDRO PEREIRA BIZTALK BLOG.

Logic Apps: CI/CD Part 3- Building your Azure Pipeline

Logic Apps: CI/CD Part 3- Building your Azure Pipeline

In the previous posts of these series, we’ve talked about how to build and prepare your Logic App for CI/CD. In this last post, I’ll show you how to build your Azure Pipeline, making it prepared for any environment you need.

If you’ve missed the other posts, here are the links for them:

Logic Apps: CI/CD Part 1- Building your Logic App

Logic Apps: CI/CD Part 2- Preparing for CI/CD

The Pipeline

Assuming you already have your repo configured, building the pipeline is fairly simple and quick. I’m not a big fan of using YAML, I find it easier to use the classic editor, having the GUI seems more appealing to me.

Having your repo in place and all the code ready, you need create the Pipeline.

As such, you need to choose the classic editor (or venture yourself in YAML) and select your repo and branch.

The available templates are helpful but if you’re just trying to deploy logic apps, I’d suggest you start with an empty job, because you might have actions that are not necessary and you’ll have to delete them.

The first thing we’re going to do, is configure the pipeline for continuous integration. It doesn’t take much to achieve this, you just need to activate the needed triggers. By default, it will filter to your main branch, but you can change this and trigger for specific projects and branches. This comes in handy when you have multiple projects and you only want to include some in the build.

After enabling the triggers, you’ll need to add the required tasks to get your pipeline going. You might be getting a few secrets in Key vault, if that’s the case, do remember to add the Azure Key Vault task. This will pull either all the secrets or the filtered ones you’ve selected, keeping them in cache for the pipeline execution. This will be used in the Replace Tokens task, which I’ll discuss a bit down the road.

As you can see, it doesn’t take many tasks to have a functional pipeline, ready to deploy your Logic App to the CI environment.

The required tasks are:

  • Visual Studio build – to build your solution, obviously
  • Copy files – which will copy the desired files over to a folder in the Drop
  • Publish build artifacts – makes the drop available to use in the pipeline and the release
  • Replace Tokens – a very handy tool that allows you to replace your tokens with the variables or group variables values
  • ARM template deployment

The Copy files task is very simple and easy to use. You take the input folder, copy the files you want/need to the target folder. Easy-peasy-lemon-squeezy.

I’d advise you to set the Target Folder as a named one, when you’re building the Release, it will be easier to find what you need if you divide your assets by name.

After copying the files, we will replace the tokens. How does this work?

Simply put, the task collects all the variables in memory and searches for the token pattern in all the target files. Given that we wrote our parameters with the __ … __ token, if we use other tokens in the files, it should not affect them. This is by far, in my opinion, the most helpful task in multi-environment deployment. It takes out the need to have multiple files by environment and having tons of variables.

Having the files copied, tokens replaced, our Logic App is ready for deployment in the CI environment. Now, this is not mandatory, you might not want to deploy your LA from the pipeline, you might want to use the Release instead. This is fine, you just need to move the ARM deployment tasks to the Release, it will not affect the outcome nor the pipeline.

As you can see, after selecting the Azure details (Subscription, RG, Location, etc) it becomes easy to select your LA to deploy. Since we used the LogicApps folder, we just need to reference the JSON files and the task will pick them up from the drop folder and deploy them.

Final notes

You’re now ready to go on your adventures and build your Logic Apps, get them ready for Continuous Integration and deploy them. I didn’t approached the Release Pipeline because it’s also very simple. You will only require to create your variables, replace your tokens and deploy the ARM templates.

You can fiddle around with gates, automated deployments, pre-deployment approvals and all, but that is a more advanced feature.

Having multiple releases that you want to joint deploy, you can even build Orchestrations (I can hear all the BizTalk bells ringing in our heads). This is not as simple as isolated deployments, because it does involve some orchestration of the parts (well, duhh).

I hope this small series of posts helped you to solve issues and to improve your deployments.

And, as always, Happy coding!

Fallout 76: o Vault Boy está de volta - Recomendações Expert Fnac

The post Logic Apps: CI/CD Part 3- Building your Azure Pipeline appeared first on SANDRO PEREIRA BIZTALK BLOG.

Logic Apps: CI/CD Part 2- Preparing for CI/CD

Logic Apps: CI/CD Part 2- Preparing for CI/CD

In the last post we talked about building a Logic App from scratch and gave a few hints on what we would change to prepare for CI/CD.

In this post, we will show you how to prepare your Logic App and template files, how to set and rename your parameters and will hint on how it will correlate with the Azure Pipeline.

So lets recap. We saw that the needed requirements are having VS installed, Azure SDK, Logic Apps for Visual Studio tools extension and an active Azure subscription. We built a new Azure Resource Group project with the Logic Apps template and added a few actions to our LA, nothing too fancy, just enough to show what’s needed.

Now, let’s look at how we will change the code to get it ready.

Changing the JSON code to prepare it for CI/CD is simple but requires attention, because if not done properly, you won’t be able to deploy your template and it might take you a while to find where the problem is. Even though VS gives you a few hints, because Intellisense helps, it might still not explain why it’s failing.

The first thing I like to do is to rename the connection parameters, having “servicebus_1_connectionString” is just horrible and does not help you understand what kind of connection you have. For this case, because we only have one connection, I’ll rename it to “arm_serviceBus_connectionString”, because we’re using an ARM (Azure Resource Manager) template and because this is the type of parameter. I will also add a template variable, named “SingleQuote”, which will be, as you’ve might have guessed, a single quote mark.

So, we end up with this:

Notice that I’ve also added the initial state control, as you may remember from a previous post about this. You can check it here: https://blog.sandro-pereira.com/2020/12/29/controlling-the-initial-state-of-a-logic-app/

If you have other connectors, I suggest you continue changing names to match the same naming convention. It will help you and others to know what that is supposed to be.

After the Logic App file is taken care of, you will also need to apply these changes in the Parameters file.

By default, it will be almost empty, just having the logicAppName parameter with a Null value. This will make your deployment fail, because the template isn’t valid.

In fact, you won’t even be able to deploy it, because VS is smart enough to prompt you for the missing values, taking the default ones from the LogicApp.

At this point, we’re no longer dealing with the definition, we’re dealing with the values we want the Logic App parameters to have. So, “type” and “defaultValue” no longer apply, you should use “value” directly or, if you’re dealing with KeyVault secrets, you can just reference KV and the secret name.

In this example, I’m setting the SB connection string both ways, to show how it can be done.

If you’ve done everything right, you’re Logic App should be deployed without any fuss.

Now comes the fun part, that is dealing with the Parameters Template file. It is incredibly difficult to do this and it’s going to take several hours. So grab that coffee and get confortable.

You will need to change your values to a token and an identifier, to later use in the Pipeline and releases.

Wow, that took us… 30 seconds, maybe. I’m exhausted and I need a break. You can even get that KV value with the token, you just need to change the identifier to the KV secret name.

We’re sweating over here with all this work.

In the next blog post, we will build the Pipeline and give the hints for the Release as well.

Happy coding!

The post Logic Apps: CI/CD Part 2- Preparing for CI/CD appeared first on SANDRO PEREIRA BIZTALK BLOG.

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

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!

The post BizTalk Server: Automation Deployment with Azure DevOps – Deploying the Project appeared first on SANDRO PEREIRA BIZTALK BLOG.