posts

There are many options in Azure for storing application dependencies, for container/docker images you can use Azure Container Registry and for development packages you can use Azure DevOps Artifacts (Nuget, npm, Maven or Python) or Github Packages (Nuget, npm, Docker, Maven or RubyGems). Third Party products like JFrog Artifactory or SonaType Nexus Repository offer alternative options if you are prepared to provision the virtual machines to run them.

The compute behind Azure DevOps pipelines comes in the form of build agents. By default pipelines will run on a Microsoft Hosted agent (typically an Azure Virtual Machine running in the same geography as your Azure DevOps Organisation). The problems with Hosted agents come when you need more control over the machines that run them, broadly these issues fall into the following categories..

Deployment scripts are a great addition to ARM/Bicep that let you execute custom code as part of a deployment. The scripts run as an Azure Container Instance and, if successful, are cleaned up once complete.

How to handle deployments of APIs into API Management is something I have spoken about (see here) and written about (see here and here) a bit before. Typically I use examples of loading a REST API by importing the OpenAPI or Swagger file and augumenting it with API Managements own policies. However, there are still a lot of XML/SOAP based APIs out there and API Management definitely has a place in modernising and protecting these systems.

This week Microsoft announced the arrival of the preview of Mounting Azure Storage as a local share in App Service

In Part 1 we talked about the process of taking an API from a yaml file to an ARM template, in this part we will recreate the process in github actions and give you a pipeline to generate and deploy those templates to Azure.

You may have noticed a theme around API management recently, I spend a lot of time talking to people about this product and like to share the patterns I see in the wild. I split this post up into 2 parts, we will begin with understanding the process before moving on to Part 2 where we will create the github actions.

This one is a bit of a gotcha around building an API Management (APIM) resource using ARM templates and concerns the diagnostic settings, shown below….

I was digging around the APIM policies recently and came across authenticate-managed-identity (docs) and started to experiment, this blog post is the culmination of those experiments.

API Management is a great tool for “fronting” your companies APIs and has some powerful tools to shape and transform those operations. One such tool is the set-body policy. This policy lets you shape either the request sent to the backend (if placed in the <inbound> element) or the response sent to the client (if called in the <outbound> section). The policy works in one of 2 ways, using code snippets (C# with a subset of the .net framework) or using liquid templates. The code snippets are great for minor modifications (e.g. remove or add a property to the existing body) but liquid templates give you an editor experience that is closer to the expected output.

One little known feature of Azure DevOps Pipelines is the ability to tag a pipeline run. By default this is a manual process.
Once the build has completed you select Edit Tags and add the values.

Consider the scenario, you are deploying an ARM template for an Azure storage account. You want to reuse the same template in multiple environments. The storage account is using the local firewall to restict access. Each environment has a different set of ip rules that need to be applied (both in number and values). How do you ensure that the ipRules can be passed as an array and applied correctly? (Note: I am using a storage account and ipRules as an example here, the same should apply to any array property on an ARM template)

I spend a lot of my day in VSCode, it has replaced “full-fat” Visual Studio for small projects (although I still prefer it for .net development) and has superceded the notepad/notepad++’s of the world for general quick editing. (This blob post is being written in markdown in vscode for example). Over the last year the options for how you run vscode have become numerous and need a little explaining so lets start with how the application is structured.

** This article was originally written about the preview of Blob versioning, the feature was made generally avaialble in September 2020 **

If you need to access network restricted resources from github actions you need to host your own runners within the network. This post shows how to provision and install VMs to act as runners using Terraform.

Azure DevOps artifacts has the ability to promote Packages between different states, this is useful if you want to test different versions of a package with limited audiences (who accept the risk).