In one of our deployments we use deploymentScripts. We use it to apply SQL migration scripts and assign SQL principals and roles in a piece of test software that persists metrics for specific test runs.
What I noticed recently is that the deployments are taking 7+ minutes to finish, even when nothing has changed in the infrastructure.

The problem

After reading the docs for a bit, I discovered we set the forceUpdateTag to the current deployment time via a parameter (param deploymentTimestamp string = utcNow('yyyyMMdd-HHmmss')). This property states the following:

Gets or sets how the deployment script should be forced to execute even if the script resource has not changed. Can be current time stamp or a GUID.

Because of the way we set the property, the deployment scripts are invoked EVERY time we run a new deployment. While that might not sound like it should have much impact because it’s just a small PowerShell script, it’s important to understand what a deployment script is doing under the hood.

A deploymentScripts resource does not run inline. It provisions a real Azure Container Instance (ACI) as the execution environment. The full lifecycle per script execution is:

1. ARM provisions an ACI container and storage account
2. The ACI pulls the specified container image, in our case azPowerShellVersion: '14.0', a multi-hundred-MB image
3. The PowerShell script executes inside the container
4. On success (cleanupPreference: 'OnSuccess'), the ACI is torn down along with the storage account

This lifecycle can take 3-5 minutes per script under normal conditions, not because the SQL work takes a long time, but because of the ACI cold-start overhead. Because we have two deployment scripts with a dependency between them, they run sequentially and each deploys its own infrastructure, doubling the total time.

I’m working on something where I need to deploy multiple versions of my software and validate whether there’s an improvement or regression. The solution heavily relies on deployed language models, so that’s something we want to evaluate first.
The solution I’m working on looks fairly similar to the setup in my Trial & Error GitHub repository, so I have a .NET frontend service and a Python backend service, both invoking language models deployed in Microsoft Foundry.

The baseline

I’ve deployed this using the following services:

• Azure API Management
  This is the public entry point for my services
• Azure Container Apps Environment
  Hosting two Container Apps for both .NET and Python
• Microsoft Foundry + some models For my agents & MAF to work with

Of course, there are some other resources deployed too, but those aren’t important for now.

The way this works is:

1. A client makes an HTTP request
2. APIM processes the request and routes it to the default backend, the .NET Container App
3. The .NET Container App takes the request and processes it
4. The request gets forwarded to the Python Container App, which processes it
5. The processed request is passed along to a language model in Microsoft Foundry
6. The response gets processed and sent back to the client through the .NET Container App and APIM

  sequenceDiagram
    participant Client
    participant APIM as Azure API Management
    participant NET as .NET Container App
    participant Python as Python Container App
    participant Foundry as Microsoft Foundry (LLM)

    Client->>APIM: HTTP Request
    APIM->>NET: Route to default backend
    NET->>Python: Forward request
    Python->>Foundry: Send to language model
    Foundry-->>Python: Model response
    Python-->>NET: Processed response
    NET-->>APIM: Return response
    APIM-->>Client: HTTP Response

I think you’ll find this to be a common design. Obviously, the .NET and Python services also provide some additional value on top of forwarding requests, but that’s not relevant to this post.

For those of you who are following me on Twitter, you might have seen my Philips Hue bridge was acting up in the past couple of months. Major bandwith usage, automations not being triggered at the appropriate times, and even the internet connectivity wasn’t working anymore. The bridge is also about 14 years old, so it might have been its time to shut down.
A relative cheap solution would be to buy a new Philips Hue bridge and set that up. However, lots of my friends are very fond of Home Assistant to automate everything, including their Hue lights. Because everyone is so positive about it, I thought I’d look into it too.

From what I understand, Home Assistant is a platform with a nice frontend application which enables user to add devices to it, so they can be used to automate stuff. For example: when turning on an Xbox, also turn on the lights in the game room.
I’m not sure how many devices are supported, but it looks like hundreds (or thousands) can be integrated. At least most of the popular devices are supported for automation.

In the IoT world there are two major communication protocols, Zigbee & Z-Wave. For a consumer, like me, they’re pretty much the same. The protocols differ on a technical level, of course. For Home Assistant to talk to my Hue lights and accessiories it needs some kind bridge to make sure the machine where Home Assistant is running on can communicate with the Zigbee hardware. For this, I’ve bought the Zigbee 3.0 USB Dongle Plus.

In my previous post, I wrote how to create & host private build agents for Azure DevOps running in Azure Container Instances.
One of the reasons for doing so is to eliminate creating build agent VM’s and performant pipelines for my side projects. But, of course, the build agents also need to be as cheap as possible. Azure Container Instances have per-second billing, which is excellent for build agent containers.

The thing is, I don’t want to turn them on or off manually.
It would be great to have an automated process turn on the agents when necessary and turn them off when done.

I started looking for a trigger or webhook that I can invoke whenever a build or release is put on the queue, but I couldn’t find such a feature in Azure DevOps. However, I did find some functionality in the Azure DevOps REST API which can be helpful in my scenario.

Azure DevOps REST API

When going through the documentation, you will probably get confused about the terminology quite fast, or at least I did. At first, I was going through the Pipelines docs and made some queries, but from this, I didn’t get the responses I expected.

Authorization

The Azure DevOps REST API works with Basic Auth. When invoking an endpoint, you have to specify an empty username and a Personal Access Token as a password to get access.
When testing in Postman, this will look similar to the following screenshot.

I’ve been complaining for a while about how slow the hosted build agent in Azure DevOps is. The reason for this is simple, as it’s a shared, free, hosted agent.
A solution for this is to host your agents, for example, via a virtual machine.

I’m not a big fan of maintaining virtual machines, and then it struck me that we now have containers that are sort of the same but easier to manage.
A container is based on a specific image, and every time you spin it up, it uses the same image (baseline). This makes sure no funny business is happening in the container, and manual modifications to the system will are deleted whenever a new container is spun up.

The build agent image

As a .NET developer, we needed Windows agents. Nowadays, we can build our solutions on a Linux machine. A great benefit from this is, Linux images are much smaller compared to their Windows counterparts. Another benefit, which I learned from experience, builds are much faster on a Linux machine. File operations in specific are way faster on a Linux operating system (NuGet/NPM).

There is a step-by-step sample on the Azure DevOps documentation site on how to create an Azure DevOps build agent, which I’ve also used myself.