IntegrationWorkz

It has been years ago I started applying continuous integration (CI) and continuous deployment (CD) principles at work. Around 2005, it was the time of Visual Studio 2005 Team System, we started using a build server in our daily development process. From then on it was no longer more: "it works on my machine". With every check-in of code changes a CI build was started which compiled your code and run unit tests which verified the quality of your code.  Deployment was in the beginning still a process of manually copying build artifacts and script files to servers and doing the installation process based on the instructions from the deployment manual (if available). Gradually it migrated to scripts (mix of batch/PowerShell/VBScript files) that our release automatically ran from the build server. In 2016 we migrated from our on-premise TFS 2008 based environment to the cloud solution nowadays known as Azure DevOps . We upgraded our MSBuild driven CI/CD pipelines to the new vis...

When updating some network related ARM templates I stumbled on the concept of subnet delegation. What is subnet delegation? Subnet delegation enables you to designate a specific subnet for an Azure PaaS service of your choice that needs to be injected into your virtual network. When you delegate a subnet to an Azure service, you allow that service to establish some basic network configuration rules for that subnet, which help the Azure service operate their instances in a stable manner. One of the advantages is that the service can configure for example routing policies or network security groups.  Subnet delegation and API Management When I was updating our virtual network/subnet templates I stumbled on the delegation section. "delegations": [ { "id": "string", "properties": { "serviceName": "string" }, "name": "string" } ] After doing some research about the concept I opened ...

Given our company cloud strategy, BizTalk is finite for us and we have started the transition to an iPaaS landscape based on Microsoft Azure . The BizTalk environment is replaced by an environment consisting of API Management , Logic Apps , Functions , Event Grid and Service Bus parts. One of the BizTalk HTTP APIs is exposed by API Management to internal and external consumers and is partly migrated to a Logic App already. This transformation to iPaaS should have no impact on the consumers of the API Management endpoints.  Sadly we found out this week that this was not true for one of the methods within that specific API. One of the consumers was transitioning from the BizTalk API to the version hosted in API Management. When testing the API they complained that the received an error that the HTTP Header Content-Type was not supported in their client. The value they received was application/xml instead of the BasicHttpBinding value text/xml; charset=utf-8 they needed. The deve...

Eldert Grootenboer ( Motion10 ) posted a series of blog posts around setting up CI/CD for Azure API Management using Azure Resource Manager templates. In his series he describes how you can using Visual Studio Team Services to host GIT repositories and set up a build and release pipeline for deploying your API Management service and it's APIs. This blog post is an extension on his first article wich describes the setup for deploying the API Management service and is done as a nested ARM template (as described in the linked template article). Scenario The API Management service is default hosted under Microsoft's azure-api.net DNS domain. To provide a professional experience to our developers we want to host our API Management service under our own DNS domain. The SSL certificate will be stored in Azure Key Vault and the configuration will be part of the CI/CD pipeline as described by Eldert in his blog posts. To make the scenario more production like we will store ...