Ship It: Delivery and Platform
From a pipeline that builds one container to a platform a hundred engineers use, and the measurement mistakes that make all of it look fine while it is not.
10 articles · about 89 min in total
Start with What Is CI/CD, ReallyDelivery starts as a pipeline problem and becomes an organizational one. The pipeline part is largely solved and well documented. The organizational part is where most teams are actually stuck.
The path follows that progression. Continuous integration, containers and orchestration first, because those are the mechanics. Then the things that accumulate: feature flags that were never removed, security checks bolted on afterwards, an internal platform nobody asked for.
The measurement steps near the end are the ones I would push hardest. Engineering metrics are unusually easy to get wrong in a way that looks rigorous. Counting deploys or story points produces a dashboard that goes up while the thing you cared about gets worse, and Goodhart's law does the rest.
Technical debt closes the path because it is the accumulated cost of every shortcut the earlier steps let you take. It is a real thing with a real interest rate, and treating it as a moral failing rather than a financing decision is why it never gets paid down.
Key takeaways
- A container packages an application and its dependencies while sharing the host kernel, which is why it starts in milliseconds where a virtual machine takes seconds.
- Feature flags left in place after a rollout become permanent branching in the codebase, so removal has to be part of the rollout plan rather than a later cleanup.
- Engineering metrics that count output, such as deploys or story points, reliably improve while the underlying outcome degrades, which is Goodhart law in practice.
- An internal developer platform is only worth building once the same friction is being solved repeatedly by different teams.
Step 1: What Is CI/CD, Really
CI/CD is three different ideas people mash into one acronym, and getting the distinction wrong is how teams end up with a pipeline that runs tests but ships nothing. Here is what continuous integration, delivery, and deployment actually mean.
Jun 4, 2026 · 8 min read
Step 2: Docker vs Virtual Machines: What a Container Actually Is
Everyone repeats that VMs virtualize hardware and containers virtualize the OS. True, but it hides the real thing. A container isn't a tiny VM. It's a normal process on the host with blinders on, fenced off by two Linux kernel features.
Jun 9, 2026 · 10 min read
Step 3: Kubernetes in Production: The 2025 Survival Guide
Hard-won lessons on running Kubernetes at scale, from cluster architecture and RBAC to cost optimization and real production pitfalls.
Mar 5, 2026 · 12 min read
Step 4: A Feature Flag Is a Production Change That Skips Your Deploy Pipeline
Two costs land the moment you add a flag, and neither is visible that day. It creates a branch in your code that nothing will ever make you delete, and it lets someone change production behavior without passing through any of the safety machinery you built for changing production behavior.
Jul 29, 2026 · 9 min read
Step 5: DevSecOps Done Right: Embedding Security into Every Stage of Your Pipeline
A practical guide to shifting security left: SAST, DAST, container scanning, secrets detection, IaC analysis, and GitHub Actions hardening.
Feb 25, 2026 · 9 min read
Step 6: Platform Engineering Is Mandatory Now. Here's the Minimum Viable IDP.
90% of organizations now run an internal developer platform, per the 2025 DORA Report. You don't need Backstage and twelve operators to get there. You need a portal, a paved path, and FinOps guardrails, and you can ship all three without a platform empire.
May 15, 2026 · 11 min read
Step 7: The Developer Experience Scorecard
Vanity metrics won't tell you why engineers are miserable or slow. Here's the measurement framework that actually surfaces the friction points worth fixing.
Jan 21, 2026 · 7 min read
Step 8: Engineering Metrics Anti-Patterns
Velocity theater is real and most engineering teams are running it. Here are the metrics that actively damage culture and what to track instead.
Jan 9, 2026 · 6 min read
Step 9: Technical Debt Is About Interest, Not Ugly Code
Ward Cunningham coined the metaphor in 1992 and meant something precise: ship code that reflects your current, partial understanding, then rewrite it once you understand better. He never meant careless code. The difference decides whether your refactoring budget gets approved.
Sep 5, 2026 · 9 min read
Step 10: A Blueprint for Platform Modernization
Most modernization efforts stall not because the technology is wrong but because the prioritization and org alignment are. Here's the framework that actually gets legacy systems replaced without halting delivery.
Jan 6, 2026 · 8 min read
Frequently asked questions
- What is the difference between a container and a virtual machine?
- A virtual machine emulates hardware and runs a complete guest operating system. A container shares the host kernel and isolates only the process and its filesystem. That is why containers start in milliseconds and are much smaller, and why they provide weaker isolation.
- Do we need Kubernetes?
- Only if you have the problems it solves: many services, several teams, and a genuine need for scheduling and self-healing across a fleet. For a handful of services, a managed container runtime delivers most of the benefit with a fraction of the operational burden.
- What is feature flag debt?
- It is the accumulation of flags that outlived their rollout. Each one is a live branch in the code that must keep working, be tested, and be reasoned about. Past a certain count the combinations become untestable, which is when flags start causing the outages they were meant to prevent.
- Which engineering metrics are actually worth tracking?
- Ones tied to outcomes rather than output: change lead time, deployment frequency, change failure rate and time to restore. They resist gaming better than counts of commits, deploys or story points, though no metric survives being turned into a target.