The twelve-factor app methodology's "Build, release, run" principle mandates a strict separation between these three stages. The build stage converts code into an executable bundle. The release stage combines this build with configuration, creating an immutable release. Each release must have a unique identifier (e.g., a timestamp or version number) to enable easy tracking and robust rollback capabilities. The run stage simply executes a specific release. This separation ensures a predictable and reliable deployment pipeline where changes are introduced by creating new releases, not by modifying existing ones or altering code at runtime.

A. Code changes at runtime are explicitly forbidden by this principle, which requires immutable releases to ensure stability and predictability.
D. Releases must be immutable. Any change, such as a new code build or a configuration update, must result in a new release.
E. The build stage, not the release stage, is responsible for compiling code, fetching dependencies, and creating assets and binaries.

1. The Twelve-Factor App, V. Build, release, run. (https://12factor.net/build-release-run). The canonical source states, "The twelve-factor app uses strict separation between the build, release, and run stages." It also specifies, "Every release should always have a unique release ID..." and that "Releases are an append-only ledger and a release cannot be mutated once it is created." This source also clarifies that the build stage compiles binaries and assets.

2. Red Hat OpenShift Documentation, "Architecting applications for OpenShift". (https://docs.openshift.com/container-platform/4.12/applications/twelve-factor-applications.html). In the section "Build, release, and run," the documentation emphasizes, "A key aspect of the twelve-factor methodology is to have strict separation between the build, release, and run stages." This vendor documentation confirms the principle's importance in modern cloud-native platforms.