Loud & Abrasive

Databases are important for most applications, but keeping their schemas consistent across versions and environments can become a sticky date pudding without proper care. Tools like RoundhousE provide streamlined, repeatable, script-based migrations and work like a charm out of the box. If using the very cool and atmospheric Azure SQL Elastic Pools, however, the default behavior lands us adjacent to the pool, not in it. Let’s not be hasty to abandon database host nor migrator; it’s easy to correct this with little configuration.

Unsurprisingly, App Services are one of Azure’s more useful and persistent offerings. Somewhat surprising (to me at least) is that WebJobs stand firmly beside them, after seeming like a tack-on, albeit a cool one. The way they are developed has evolved, however, now leveraging the same SDK that Azure Functions is built on. From a user’s perspective, WebJobs’ deploy-and-run-time is conversely unchanged. Unfortunately, that means deploying them is primarily advertised as a manual process from Visual Studio, the Azure Portal, or using Powershell. We know better, though, and can integrate WebJobs with our App Services in Azure DevOps Pipelines, even if we’re straying from the happy path.

I’ve become a big fan of Azure DevOps Pipelines. It’s a powerful and robust tool that enables really slick automated build and release processes. I wrote last about sexy auto-semversioning Nuget libraries using Build Pipelines. I’m still no expert in AzDO but am continuing to extend and improve the ways we leverage it. Recently I found a way to optimize against one of release pipelines’ biggest annoyances: app configuration for “non-transformable” config formats such as environment variables for Docker containers.