---
title: "V. 构建，发布，运行"
source: Twelve-Factor App
source_url: https://github.com/heroku/12factor
licence: MIT
domain: engineering
subdomain: 12factor
date_added: 2026-04-25
---

## V. 构建，发布，运行
### 严格分离构建和运行

[基准代码](./codebase) 转化为一份部署(非开发环境)需要以下三个阶段：

* *构建阶段* 是指将代码仓库转化为可执行包的过程。构建时会使用指定版本的代码，获取和打包 [依赖项](./dependencies)，编译成二进制文件和资源文件。
* *发布阶段* 会将构建的结果和当前部署所需 [配置](./config) 相结合，并能够立刻在运行环境中投入使用。
* *运行阶段* （或者说“运行时”）是指针对选定的发布版本，在执行环境中启动一系列应用程序 [进程](./processes)。

![代码被构建，然后和配置结合成为发布版本](/images/release.png)

**12-factor 应用严格区分构建，发布，运行这三个步骤。** 举例来说，直接修改处于运行状态的代码是非常不可取的做法，因为这些修改很难再同步回构建步骤。

部署工具通常都提供了发布管理工具，最引人注目的功能是退回至较旧的发布版本。比如， [Capistrano](https://github.com/capistrano/capistrano/wiki)  将所有发布版本都存储在一个叫 `releases` 的子目录中，当前的在线版本只需映射至对应的目录即可。该工具的 `rollback` 命令可以很容易地实现回退版本的功能。

每一个发布版本必须对应一个唯一的发布 ID，例如可以使用发布时的时间戳（`2011-04-06-20:32:17`），亦或是一个增长的数字（`v100`）。发布的版本就像一本只能追加的账本，一旦发布就不可修改，任何的变动都应该产生一个新的发布版本。

新的代码在部署之前，需要开发人员触发构建操作。但是，运行阶段不一定需要人为触发，而是可以自动进行。如服务器重启，或是进程管理器重启了一个崩溃的进程。因此，运行阶段应该保持尽可能少的模块，这样假设半夜发生系统故障而开发人员又捉襟见肘也不会引起太大问题。构建阶段是可以相对复杂一些的，因为错误信息能够立刻展示在开发人员面前，从而得到妥善处理。
