传送门 Twelve-Factor
简介
现代纪元，软件一般发布为一个服务，一般称为 web-apps 或着 saas. Twelve-Factors-App 是一种方法论 用来构建有如下特征的 SaaS:
- 使用声明式格式实现安装自动化，以减少部署的时间与人力成本。
- 与底层操作系统有一个干净的契约，在执行环境之间提供最大的可移植性；
- 适合在现代云平台上部署，不需要服务器和系统管理；
- 最大限度地减少开发环境和生产环境之间的差异，实现持续部署以获得最大的敏捷性
- 可以在不需要对工具、架构或开发实践进行重大更改的情况下进行扩展。
十二因素方法可以应用于以任何编程语言编写的应用程序，这些应用程序可以使用任何后台服务（数据库、队列、内存缓存等）的组合。
背景
本文档的贡献者直接参与了数百个应用程序的开发和部署，并通过他们在Heroku平台上的工作间接见证了数十万个应用程序的开发、运行和扩展。
本文档综合了我们在各种软件即服务应用程序方面的所有经验和观察结果。它是对应用程序开发的理想实践的三角剖分，特别关注随着时间的推移应用程序的有机增长的动态、开发程序代码库的开发人员之间的协作动态，以及避免软件侵蚀的成本。
我们的动机是提高对我们在现代应用程序开发中看到的一些系统问题的认识，提供讨论这些问题的共享词汇表，并通过附带的术语为这些问题提供一组广泛的概念性解决方案。该格式的灵感来自Martin Fowler的《Patterns of Enterprise Application Architecture》和《Refactoring》。
谁应该读这个文档
任何构建作为服务运行的应用程序的开发人员。部署或管理此类应用程序的运维工程师。
1. 基准代码
一份在版本控制中被跟踪的基准代码，多份部署
一个12个因素的应用程序总是在一个版本控制系统（如Git,Mercurial,Subversion）中被跟踪。一份用来跟踪代码所有修订版本的数据库的副本被称作代码库（code repository），通常缩写为 code repo 或仅 repo.
基准代码是一个的 repo （集中式版本控制系统中，如 Subversion）或者 一组共享根提交的 repos (分布式版本控制系统，如 git).
基准代码和应用程序之间始终存在一对一的关联：
- 如果有多个基准代码，那么它就不是一个应用程序，而是一个分布式系统。分布式系统中的每个组件都是一个应用，每个组件都可以单独满足12-Factors。
- 多个应用程序共享相同的代码是违反12-Factors原则的。这里的解决方案是将共享代码拆分成独立类库，通过依赖关系管理器(php composer, go mod, python gem, node npm)进行管理。
每个应用程序只有一个基准代码，可以有多份部署。每个部署是基准代码的一个运行实例。这通常是一个生产环境站点，以及一个或多个预演站点。此外，每个开发人员都有一个在本地开发环境中运行的应用程序副本，每个副本都是一份部署。
基准代码在所有部署中都是相同的，尽管每个部署中可能有使用不同的版本。例如，开发人员有一些提交尚未部署到预演版本的代码;预演环境有一些提交尚未部署到生产环境。但它们都共享相同的基准代码，因此可以识别为同一应用程序的不同部署。
未完待续…..