现如今, 软件通常会作为一种服务来交付, 即SAAS(softwaware-as-a-service). Twelve-Factor 为构建具有如下特征的SAAS提供了方法论:
- 使用标准化的配置流程, 来减少项目组加入新成员所需要的时间.
- 与底层OS 含有明确的契约, 来获得最大的执行环境可移植性.
- 适合部署在云环境中.
- 最小化开发和生产间的差异, 使用持续发布.
- 扩展(scale up) 时的代价尽可能小.
Twelve-Factor 包含以下的条款:
- Codebase.
- 一个置于版本控制下的代码库, 多份部署(dev,staging,pro).
- Dependency.
- 明确声明并隔离依赖.
- 不要隐式地依赖于系统级别的包, 和系统工具(curl).
- Config.
- 在环境(而非代码)中存储配置.
- 代码不会随着发布而变化.
- config 是会根据发布而变化的: 资源,认证,环境特定值.
- Backing Services
- 将后端服务(backing services) 视为附加资源(attached resources).
- 代码不应区分本地和第三方的服务.
- 它们都是�资源, 通过配置中的URL 来访问.
- 资源可以被随意的加载/卸载(attach/detach).
- 严格区分build,release 和run 阶段
- 从codebase 到deploy 的过程.
- 以无状态的进程的方式运行app.
- 这样有利于扩展.
- app 应该自包含的(self-contained)
- 并�通过端口绑定的方式来提供(HTTP)服务.
- 将webserver(如jetty)添加到app (code)中,而不依赖于外部执行环境.
- Process 是一等公民
- 将不同的工作分配给不同类型的process.
- app 进程�不需要守护进程或写入PID 文件, 而是依赖于OS 的进程管理器(process manager).
- Disposable(�易处理):
- app 应该可以快速地启动和优雅地关闭.
- 保持�开发和线上环境尽量一致.
- �开发和线上环境之间的�差异(gap): 时间,人员,工具.
- app 应使用�持续部署来减少两者间的差异.
- 即使adapter理论上能够隔离不同�后端服务, 但是最好还是在开发和线上环境中使用相同的后端服务. 因为不同�服务间的差异, 可能会导致代码上的分支.
- 由于包管理和虚拟化环境的出现, 轻量级的本地环境变得不再重要.
- Log
- 把log 视为事件流(event stream).
- app 本身不关心输出流的routing/storage.
- 由执行环境来负责流的归档目的地(terminal, file).
- 管理进程(admin process)
- 以一次性进程(one-off process) 的形式运行后台管理任务.
- 例如: 数据移植, 控制台脚本等.
- 以一次性进程(one-off process) 的形式运行后台管理任务.
