3 posts tagged with "CI/CD"

The "Open in Dev Container" badge is one of the highest-friction-to-value improvements you can make to a developer tool. Someone lands on your README, clicks the badge, waits for a container to build, and starts using the tool — no install steps, no certificate trust ceremony, no "is port 8899 available on this machine" questions. The conversion from "interesting project" to "I am actually running this" happens in the time it takes Docker to pull an image.

Getting there, however, requires navigating a specific class of problems that are not particularly hard once you understand them but are completely opaque until you do. This post is a technical account of building the Topaz devcontainer: the three services that ended up in the Docker Compose file, why /etc/resolv.conf defeated two consecutive DNS approaches, and what the working architecture looks like.

This week in Topaz: from page blobs to health-checked host orchestration.

This is the first post in a new weekly series: Topaz Ship Log.

Each edition is a concise, case-by-case summary of what changed in Topaz during the week, why it matters, and what it unlocks for local Azure development. This first issue covers the last 7 days of work.

Running the full test suite on every commit is simple to set up and expensive to live with. Topaz spans twelve services, each with its own E2E tests and Azure CLI tests. On a change to a single endpoint in the Container Registry service, waiting for Key Vault, Service Bus, and Event Hubs tests to finish is pure overhead. The Topaz CI pipeline solves this with a three-stage decision that maps changed files to a focused test filter — running everything only when it has to.