Loud & Abrasive

I am very happy to announce that I am the host of Headspring’s new podcast OK Human, an exploration of technology, developing, and consulting through the lenses of humanity and emotion. Look forward to discussions on work strategy, organization, empathy, and how change can impact us as people while we make (or support making) software.

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.