Build vs Run vs Deploy

The three stages

Stage	What happens	Typical output
Build	Dependencies are restored, code is compiled or bundled, and checks may run	An artifact: a package, an installer, a container image, a folder of static files
Deploy	A specific artifact is copied or installed into an environment and combined with that environment’s configuration	A new version available on a server or service
Run	The process starts, reads its configuration and serves requests or does its work	A live application

For interpreted languages the build step may be small (install dependencies, maybe bundle), but it still exists. See Compiled vs Interpreted Code.

Which problems show up where

Stage	Typical problems
Build	Compile and type errors, missing or conflicting dependencies, failing checks
Deploy	Wrong environment settings, missing files, permission problems, a different operating system or runtime version
Run	Runtime errors, bad data, missing or invalid configuration, unreachable services

Why keep them apart

Build once and deploy many times. The artifact that passed testing is the exact one that goes to production, because rebuilding for each environment risks shipping something that was never tested.

Keep configuration outside the artifact. Database addresses, keys and feature settings come from the environment at deploy or run time. See Environment Variables and Secrets Management.

Rollback is then easy. If every build is a kept, versioned artifact, going back means deploying the previous one.

“Works on my machine”

Running locally with a dev server is not the same as running a built and deployed version. Optimised output, missing files, other operating systems and different settings often show up only after the build or deploy stage. Build and run the real artifact locally now and then.

Typical commands

Commands differ per ecosystem, but the pattern is the same:

<build command>    # produce an artifact
<run command>      # start the result locally

A pipeline usually does the deployment. See CI/CD Basics and Environments.

Try it

Pick a project you work on. Find out and write down the command that builds it, what the build produces and where, and how that output reaches the test environment. Then run the built output locally instead of the dev server and note anything that behaves differently.