How Companies Ship Code to Production

Most companies do not really ship code by “moving it from dev to QA to UAT to prod”. They ship by establishing a chain of trust around one build artifact and proving, step by step, that promoting that artifact is safer than rebuilding or hand-tweaking it later.

The workflow usually starts long before a deployment job runs. Product requirements are broken into small units of work so that a change can be reviewed, tested, and rolled back independently. Whether the team uses sprints, Kanban, or continuous flow matters less than the size of the batch. Small batches are easier to reason about and reduce the blast radius of defects.

When a developer pushes code, the first real gate is continuous integration. The point of CI is not only to run unit tests. It is to answer one operational question quickly: is this exact revision safe enough to package? Typical checks include compilation, static analysis, unit tests, contract tests, dependency policy, and security scanning. Mature teams are careful about flakiness here because unreliable gates teach engineers to ignore failures, which destroys the whole value of the pipeline.

If the revision passes, the system builds an immutable artifact such as a container image, package, or signed binary and stores it in an artifact repository. This is more important than it sounds. Production should receive the same artifact that passed validation, not a fresh rebuild that might pick up a different dependency, timestamp, or environment-specific behaviour. Immutability is what makes promotion auditable.

From there, environments exist to answer different questions. A development or integration environment checks whether the service can actually boot with real infrastructure dependencies. QA environments isolate features so multiple teams can test without trampling each other. That isolation has a tradeoff: the more environments you create, the easier it is for configuration drift to creep in. If QA1, QA2, UAT, and production do not behave alike, passing tests in lower environments gives false confidence.

User acceptance testing exists because not every defect is technical. A system can pass automated checks and still violate a business rule, pricing rule, or operational process. Release candidate promotion is therefore partly a technical event and partly a decision event. Someone has to decide that the remaining risk is acceptable.

The actual production rollout is where modern delivery gets more interesting than the old linear diagram suggests. Good teams do not expose 100 per cent of traffic immediately if they can avoid it. They use canaries, blue-green deployment, rolling updates, or feature flags to limit blast radius. A feature flag is especially useful because it decouples deployment from release. You can put code in production infrastructure while still controlling who sees the behaviour.

The hardest part of shipping is often not the application binary. It is everything that changes around it: database migrations, cache format changes, queue consumers, search indexes, and external API contracts. Safe teams design rollouts so that old and new versions can coexist for a while. That means additive schema changes before destructive ones, backward-compatible event formats, and rollback plans that work after state has started to move.

Production monitoring is the final gate, not an afterthought. Once traffic hits the new release, SRE or platform teams watch service-level indicators such as error rate, latency, saturation, queue depth, and business counters. A rollout that looks healthy at the infrastructure layer can still be broken if signups, payments, or message delivery suddenly fall.

So the practical answer is this: companies ship code by reducing uncertainty in stages. Review narrows logic risk. CI narrows build risk. artifact promotion narrows supply-chain risk. staged rollout narrows blast radius. monitoring narrows detection time. The tools differ by company, but the mechanism is always the same. Safe delivery is less about a named platform and more about turning release decisions into evidence-backed routine work.