Newest first, grouped by year. Search or filter by topic.
Each Logic App in this Azure estate was split across four sibling stacks - runtime, workflows, APIM registration and service discovery - a clean lifecycle separation that quadrupled the folder, pipeline and state count per integration. Part 8 of the Terraform on Azure series.
The most-consumed custom module in an Azure Terraform estate wrote one Key Vault secret per service - a JSON record carrying a URL, a credential and a type - and quietly became the runtime service registry for scores of Function Apps and Logic App workflows. How it worked, what it got right, and where a registry with no registry starts to strain. Part 6 of the Terraform on Azure series.
With no terraform_remote_state anywhere in 230 stacks, every cross-stack reference in this Azure estate was a literal name string - a taxonomy you could read from ls, a coupling with zero runtime dependencies, and a silent-drift hazard on every rename. Part 7 of the Terraform on Azure series.
Nine thin custom Terraform modules carried the entire platform-integration story of an Azure estate. This part dissects the APIM-publication half - key minting through local-exec, SAS-splitting through PowerShell, twin modules one hyphen apart, and a typo frozen into dozens of source strings. Part 5 of the Terraform on Azure series.
Two generations of Terraform pipeline in one Azure estate - manual parameterized plan-and-apply consoles beside gated plan-artifact promotion - and why applying the exact plan you approved is the rung that matters. Part 4 of the Terraform on Azure series.
Empty backend blocks, per-environment storage accounts and a state file for every stack-environment pair - how one Azure estate partitioned a thousand Terraform states for blast radius, and what that sprawl cost. Part 3 of the Terraform on Azure series.
How workspace-keyed lookup maps and a single platform-facts JSON file let hundreds of Terraform stacks run identically in dev, staging and prod - and when a forgiving lookup default is the wrong kind of kindness. Part 2 of the Terraform on Azure series.
The conventions that let one Terraform sample library serve hundreds of Azure deployments - a five-file layout, workspace-indexed environments, pinned golden modules and pipeline-first delivery. Part 1 of a series on Terraform for the Azure estate.
A practical walkthrough of the pipeline that ships this very website: from push to production on Azure App Service, with secrets kept out of the repository and zero manual steps.
The honest ledger for the whole estate - what coordinating through tables actually cost, what genuinely earned its keep, and what I would reach for now instead of using the database as a message bus.
Four pipelines run dotnet test against projects with no tests and pass every time, the shared model ships as committed .nupkg files in a folder, one executable has no pipeline at all, and a DLL with no source hides an algorithm pasted inline elsewhere.
The same dashboard KPI is computed by three different formulas across role-variant procedures, rendered on a gauge with a sibling metric quietly deleted - and the fact table beneath it is an accidental Kimball star nobody designed.
The business month runs the 16th to the 15th, so a year-overview proc carries twelve correlated subqueries, five-day-capped weeks, time averaged through float casts and contractor filters that drift by a digit between copies.
One hierarchy, three implementations - a recursive CTE, a view that calls a scalar function on every row, and a whole family of tree procs - plus a relationship flag that is a decimal number pretending to be binary.
Thirty-eight tables, fourteen foreign keys, none on the tables that need them - plus a shipped SSMS template index, auto-tuning suggestions accepted blind, three-state booleans and a demo mode that mutates production master data.
The same database solves the same sortable-paging problem twice - once by concatenating user input straight into EXEC, once with a CASE whitelist, QUOTENAME and sp_executesql. A side-by-side of the wrong and right answer.
UTC timers, IST badge gates, DateTime.Now in one executable and UtcNow in the next, columns that record neither - how a system whose entire product is timestamps got away with never deciding what time it is.
Every five minutes a function hunts for people still virtually swiped in past ten hours and emails them - magic node numbers, an at-most-once flag with a gap in it, and a local config file pointing straight at production.
A 22-character job name, a 20-character column, and an error handler that has thrown on every attempt since the day it shipped - plus the four parallel logging systems that still could not catch it.
When one job needs another to redo work, it leaves a row - an action enum, a rewind date and a Done flag standing in for a message broker, plus the delete-and-replay proc that makes reruns possible.
The shift calculator writes one report row per employee per day since 2019, inventing blank rows for days nobody badged - a dense date spine built from sentinel values, at the price of one database round-trip per row.
Four magic strings in an audit column decide which rows the batch jobs may overwrite and which belong to humans - provenance, workflow state and inter-job protocol smuggled into a field meant for names.
Badge gates record when you arrived, not which shift you worked - so the platform infers it, scoring every candidate shift by L1 distance in time-of-day space and letting the smallest number win.
The leave sync resumes from wherever its own job log last said Success - one table serving as log, watermark and metrics store at once, with recursive pagination on top and an envelope check in exactly the wrong place.
Leave records arrive late, change and get cancelled - so the sync reaches back into already-approved attendance rows and re-derives them, carefully stepping around human decisions and allowance money.
