From 1696dfa695b4b136cfacf83c365108e389d3ecb2 Mon Sep 17 00:00:00 2001 From: Daniel Jomphe Date: Thu, 8 Dec 2011 19:08:01 -0500 Subject: [PATCH] fix typos --- content/build-release-run.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/build-release-run.md b/content/build-release-run.md index 9beb1b4..b0ed3ed 100644 --- a/content/build-release-run.md +++ b/content/build-release-run.md @@ -11,9 +11,9 @@ A [codebase](/codebase) is transformed into a (non-development) deploy through t **The twelve-factor app uses strict separation between the build, release, and run stages.** For example, 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. -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. Its `rollback` command makes it easily to quickly roll back to a previous 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. Its `rollback` command makes it easy to quickly roll back to a previous release. -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. +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 change must create a new release. Builds are initiated by the app's developers whenever new code is deployed. 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.