DevOps Practices That Actually Ship

DevOps is a discipline, not a toolchain. Buying Terraform and a GitHub Actions plan does not make a team DevOps any more than installing a treadmill makes someone an athlete. The actual work is the steady reduction of delivery friction: smaller changes, shorter feedback loops, fewer hands on keyboards during a release, and a recovery path that does not depend on whoever happens to still be awake at 3 AM.

The articles in this collection treat DevOps as the work of removing accidental complexity from the path between a commit and production. That means pipelines that are deterministic rather than optimistic, infrastructure that can be rebuilt rather than nursed, and observability that produces decisions rather than dashboards. Lead time, deployment frequency, change failure rate, and recovery time are tracked because they expose where flow actually breaks — not because they decorate a quarterly review.

A recurring theme is shared ownership. Pipelines that only one team can debug are not pipelines, they are bottlenecks with green checkmarks. Articles cover the cultural reshaping that has to happen alongside the tooling: how product, platform, and operations stop throwing artifacts over a fence and start treating delivery as a single problem with a single team.

Another theme is automating away toil — and recognising when automation itself becomes toil. Not every manual step deserves a script. Some deserve to be deleted, others to be moved into a self-service paved path, and a few to stay manual because the failure mode is worse than the friction. The articles name those trade-offs explicitly rather than assuming more automation is always better.

Expect direct opinions on CI/CD anti-patterns, the flaky-test tax that quietly funds itself out of feature time, security gates that exist on paper only, and platform investments that genuinely burn down operational risk versus those that just create new dashboards to ignore. If you are looking for maturity-model theatre, this section is not it.

Platform Engineering Without Backstage: Pragmatic IDPs on Azure

Every platform engineering conference talk in the last two years has had a Backstage slide. Glossy catalogue screenshot, a scaffolder demo that creates a repo in four clicks, a knowing nod about “developer experience”. What the slide never shows is the six months the team spent building plugins, the Postgres instance somebody now babysits, the TechDocs theme nobody asked for, and the 0.4 of an engineer permanently assigned to chasing Backstage’s two-week release cadence.

There is no shame in any of this. Backstage is a serious project and serious teams run it well. The shame is treating it as the default (the thing you reach for on day one) when most teams could ship 80% of the value with a tenth of the effort and a fraction of the running cost. Backstage is a platform for building platforms. Most teams need a platform, not a platform-platform.

This post is the Internal Developer Platform (IDP) I keep building when nobody is forcing me to use Backstage. It is small, opinionated, runs on Azure plumbing you already pay for, and ships value in the first quarter instead of the third year.

AI Code Review Is a Sycophant

AI code review tools are genuinely useful for catching syntax errors, obvious bugs, and common anti-patterns. They are also systematically unable to tell you that the feature you built was the wrong call, that the abstraction is off, that the naming reveals confused thinking, or that the correct review comment is “delete this.” Here is what AI reviews find, what they miss, and why human judgment still has no substitute.

.claudeignore Doesn't Exist. Here's What Does.

Claude is indexing your bin/ and obj/ directories right now. You asked it how to stop that. It told you about .claudeignore. You added it, committed it, and felt responsible. There is just one problem: .claudeignore does not exist. Claude invented it, the internet spread it, and your secrets were never protected. Here is what actually works.

Your Privacy Docs Are Fiction: Let's Fix That with .NET CLI Tools

Spreadsheet-based privacy audits examine yesterday’s system while today’s code deploys undocumented PII. Build .NET CLI tools that discover all personal data, catch expired consents, and verify deletions. Then fail builds when compliance breaks.

Security Tests That Prove Themselves

Your security tests run. They pass. But can you prove when they ran and against which code version? Most security testing lives in Word documents, Postman exports, and screenshot folders on SharePoint. The tests themselves might be valid. The evidence trail is not. This article shows how to build CLI-based test suites using xUnit and WebApplicationFactory that generate their own proof: structured logs with timestamps, commit hashes, and correlation IDs captured automatically in CI/CD pipelines. No more quarterly reports that could have been written yesterday. Instead, 847 test executions across 23 deployments, each linked to a specific commit and preserved for 90 days.