kennethreitz/12factor
1
0
Fork 0
mirror of https://github.com/kennethreitz/12factor.git synced 2026-06-05 23:10:17 +00:00
Code Issues Packages Projects Releases Wiki Activity

build/release/run improvements - this one is still messy

Browse Source
This commit is contained in:
Adam Wiggins
2011-06-05 12:28:05 -07:00
parent 8f992eaa36
commit 3931a2952e
1 changed files with 6 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/build-release-run.md
+6 -4
View File
@@ -1,13 +1,15 @@
## V. Build, release, run
### Strict separation of build stage and run stage
The *build stage* is a transform which converts a [code repo](/codebase) into an executable bundle with no external dependencies, suitable for immediate execution in the execution environment. This bundle is known as a *build*. The build stage typically checks out a fresh copy of the code at a commit specified by the release process, fetches and vendors dependencies, and compile binaries or assets. One example of a build stage is creating a JAR file for a Java (or other JVM-based) language.
The process of turning a [codebase](/codebase) into a running app passes through three stages:
The *run stage* (also sometimes referenced as "at runtime") takes the build produced by the build stage and executes it in the execution environment. This typically happens by fetching and expanding the build, setting up the environment with the [config](/config), and then launching one or more of the app [processes](/processes).
* The *build stage* is a transform which converts a code repo into an executable bundle known as a *build*. Using a version of the code at a commit specified by the deployment process, the build stage fetches and vendors [dependencies](/dependencies) and compiles binaries and assets.
* The *release stage* takes the build produced by the build stage and combines it with the deploy's current [config](/config). The resulting *release* contains both the build and the config and is ready for immediate execution in the execution environment
* The *run stage* (also sometimes referenced as "at runtime") runs app against the current release. This typically happens by fetching and expanding the build, setting up the environment with the [config](/config), and then launching one or more of the app [processes](/processes).
In a traditional server-based hosting environment, it's easy to muddle together the build and run stages. For example, one might create the fresh checkout and install dependencies, but then tweak the code in-place on the disk of the production deploy.
In a traditional server-based hosting environment, it's easy to muddle together these stages. For example, a developer might create the fresh checkout and install dependencies (a build), but then tweak the code in-place on the disk of the production deploy (violation of stage separation).
**The twelve-factor app uses strict separation between the build and run stages.** It is impossible to make changes to the code at runtime, since there is no way to propagate those changes back to the build stage. Config is accessible at runtime but not at build time, since config can change without triggering a build.
**The twelve-factor app uses strict separation between the build, release, and run stages.** It is impossible to make changes to the code at runtime, since there is no way to propagate those changes back to the build stage. Config is accessible at runtime but not at build time, since config can change without triggering a build.
Builds must be initiated by a developer, as an essential part of the process of deploying new code. Runtime execution, by contrast, can happen automatically in cases such as a server reboot, or a crashed process being restarted by the process manager. Therefore, the run stage should be kept to as few moving parts as possible, since problems that prevent an app from running can cause it to break in the middle of the night when no developers are on hand. The build stage can be more complex, since errors are always in the foreground for a developer who is driving the deploy. A failed build must abort the release process and avoid any disruption of the running app.