Principle #5: Build, Release, Run
Goal: Separate the process of building your application from releasing it and running it, so deployments are predictable, repeatable, and easy to roll back.
What It Means
The Build, Release, Run principle divides your deployment pipeline into three distinct stages:
Build Stage
- Converts your source code into an executable bundle.
- Installs dependencies, compiles assets, and packages the application.
- Output: a build artifact (e.g., Docker image, compiled files).
Release Stage
- Combines the build artifact with the configuration for a specific environment.
- Each release is uniquely identified and immutable.
- This is the version you deploy.
Run Stage
- Executes the app in the target environment.
- Runs the code exactly as packaged in the release stage.
Why It Matters
- Predictability: Ensures the same code and config go to production every time.
- Rollback Safety: You can revert to a previous release if something goes wrong.
- Consistency: Prevents last-minute code changes during deployment.
- Efficiency: Clear separation of steps makes automation easier.
Example
A company deploys a Node.js web app:
-
Build:
npm installruns in a CI/CD pipeline, producing a Docker image. - Release: The Docker image is paired with production environment variables.
- Run: The image is started in Kubernetes pods for production.
If an issue appears, the team can redeploy the previous Docker image instantly.
Best Practices
- Keep build, release, and run as separate steps in your CI/CD pipeline.
- Make releases immutable — never modify an existing release.
- Tag releases for easy rollback.
- Automate the entire process to reduce human error.
- Store build artifacts in a secure, versioned repository.
Takeaway: Separating build, release, and run ensures consistent deployments, easier troubleshooting, and safer rollbacks — a cornerstone of reliable software delivery.
Top comments (0)