diff --git a/content/build-release-run.md b/content/build-release-run.md index 00dcd78..1e12bde 100644 --- a/content/build-release-run.md +++ b/content/build-release-run.md @@ -1,20 +1,25 @@ ## V. Build, release, run -### Separate build and run stages +### Strict separation of build stage and run stage -The *build* stage is a transform which converts a [code repo](#) into an executable bundle with no external dependencies, suitable for immediate execution in the execution environment. This bundle is known as a *build* (noun). 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 well-known example of a build stage is creating a JAR file for a Java (or other JVM-based) language. +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 *run* stage (commonly also referred to as "at runtime") takes the bundle produced by the build stage and executes it in the execution environment. This typically happens by fetching and expanding the executable bundle, setting up the environment with the [config](#), and then launching one or more of the app [processes](#). +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). -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. +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. -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 (or to other runtimes). Config is only accessible at runtime, since config can change without triggering a build. +**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. -Builds only happen as the result of a developer-initiated action: deploying new code. Runtime execution, however, can often happen automatically in cases such as a server reboot, or a process restarting after it crashes. 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 around. The build stage can be more complex, since errors are always in the foreground for a developer who is actively engaged, and a failed build will abort the release process and avoid disrupting the running application. +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. -### Release = build + config +#### Release = build + config + +![Code becomes a build, which is combined with config to create a release.](/images/release.png) A *release* is a combination of a build (an executable bundle generated in the [build stage](#)) and a [config](#), a set of environment variables to determine runtime behavior. New builds always trigger new releases (since the build has been updated). Config changes also trigger a new release (since the config has been updated). A release requires restarting all running [processes](#) in order to bring all processes onto the new release. Deployment tools typically offer release management tools, most notably the ability to roll back to a previous release. For example, the [Capistrano](https://github.com/capistrano/capistrano/wiki) deployment tool stores releases in a subdirectory named `releases`, where the current release is a symlink to the current release directory; and offers a `rollback` command. + +Every release should always have a unique release ID, such as a timestamp of the release (such as `2011-04-06-20:32:17`) or an incrementing number (such as `v100`). Releases are an append-only ledger and a release cannot be mutated once it is created. Any changes must create a new release. + diff --git a/content/toc.md b/content/toc.md index f9e4501..bc718d2 100644 --- a/content/toc.md +++ b/content/toc.md @@ -14,7 +14,7 @@ The Twelve Factors ### Treat backing services as attached resources ## [V. Build, release, run](/build-release-run) -### Separate build and run stages +### Strict separation of build stage and run stage ## [VI. Processes](/processes) ### Stateless, disposable processes handle application logic diff --git a/public/images/release.png b/public/images/release.png new file mode 100644 index 0000000..a4a066e Binary files /dev/null and b/public/images/release.png differ