I. 基准代码( 二 ) _代码管理

IV. 后端服务把后端服务当作附加资源
后端服务是指程序运行所需要的通过网络调用的各种服务，如数据库（MySQL，），消息/队列系统（，），SMTP 邮件发送服务（），以及缓存系统（）。
类似数据库的后端服务，通常由部署应用程序的系统管理员一起管理。除了本地服务之外，应用程序有可能使用了第三方发布和管理的服务。示例包括 SMTP（例如），数据收集服务（例如New Relic或），数据存储服务（如 S3），以及使用 API 访问的服务（例如, Maps,Last.fm）。
12- 应用不会区别对待本地或第三方服务。对应用程序而言，两种都是附加资源，通过一个 url 或是其他存储在配置中的服务定位/服务证书来获取数据。12- 应用的任意部署，都应该可以在不进行任何代码改动的情况下，将本地 MySQL 数据库换成第三方服务（例如 RDS）。类似的，本地 SMTP 服务应该也可以和第三方 SMTP 服务（例如）互换。上述 2 个例子中，仅需修改配置中的资源地址。
每个不同的后端服务是一份资源。例如，一个 MySQL 数据库是一个资源，两个 MySQL 数据库（用来数据分区）就被当作是 2 个不同的资源。12- 应用将这些数据库都视作附加资源，这些资源和它们附属的部署保持松耦合。

文章插图
部署可以按需加载或卸载资源。例如，如果应用的数据库服务由于硬件问题出现异常，管理员可以从最近的备份中恢复一个数据库，卸载当前的数据库，然后加载新的数据库 – 整个过程都不需要修改代码。
V. 构建，发布，运行严格分离构建和运行
基准代码转化为一份部署(非开发环境)需要以下三个阶段：

文章插图
12- 应用严格区分构建，发布，运行这三个步骤。举例来说，直接修改处于运行状态的代码是非常不可取的做法，因为这些修改很难再同步回构建步骤。
部署工具通常都提供了发布管理工具，最引人注目的功能是退回至较旧的发布版本。比如，将所有发布版本都存储在一个叫的子目录中，当前的在线版本只需映射至对应的目录即可。该工具的命令可以很容易地实现回退版本的功能。
每一个发布版本必须对应一个唯一的发布 ID，例如可以使用发布时的时间戳（2011-04-06-20:32:17），亦或是一个增长的数字（v100）。发布的版本就像一本只能追加的账本，一旦发布就不可修改，任何的变动都应该产生一个新的发布版本。
新的代码在部署之前，需要开发人员触发构建操作。但是，运行阶段不一定需要人为触发，而是可以自动进行。如服务器重启，或是进程管理器重启了一个崩溃的进程。因此，运行阶段应该保持尽可能少的模块，这样假设半夜发生系统故障而开发人员又捉襟见肘也不会引起太大问题。构建阶段是可以相对复杂一些的，因为错误信息能够立刻展示在开发人员面前，从而得到妥善处理。
VI. 进程以一个或多个无状态进程运行应用
运行环境中，应用程序通常是以一个和多个进程运行的。
最简单的场景中，代码是一个独立的脚本，运行环境是开发人员自己的笔记本电脑，进程由一条命令行（例如 .py）。另外一个极端情况是，复杂的应用可能会使用很多进程类型，也就是零个或多个进程实例。
12- 应用的进程必须无状态且无共享。任何需要持久化的数据都要存储在后端服务内，比如数据库。
内存区域或磁盘空间可以作为进程在做某种事务型操作时的缓存，例如下载一个很大的文件，对其操作并将结果写入数据库的过程。12-应用根本不用考虑这些缓存的内容是不是可以保留给之后的请求来使用，这是因为应用启动了多种类型的进程，将来的请求多半会由其他进程来服务。即使在只有一个进程的情形下，先前保存的数据（内存或文件系统中）也会因为重启（如代码部署、配置更改、或运行环境将进程调度至另一个物理区域执行）而丢失。