DevOps实践系列文章，请参见连接。
描述
在一个软件产品公司中，一般的基础设施会包括在每个产品线上的各种环境、以及针对这些环境构建起来的部署流水线。
- local：本地开发环境
- dev：内部开发环境
- mock：团队间协作时使用的模拟环境
- test：供测试人员测试环境
- performance：非功能需求测试环境
- stage：试运行环境（新功能部分目标用户使用）
- production：对外开放的产品环境
一个已经上线的正式产品，第一要务就是保证线上系统是稳定可靠运行的。所以需要通过各种手段保证新功能上线，线上系统问题的快速反馈与立即解决。根据不同公司产品形态的不同，每个公司都需要有一套功能上线流程以保证线上系统的正常运行。
上图中比较详尽的描述了一个功能从开发到上线的整体过程。且在过程中每一个过程都由不同的角色参与。最终保证系统在线上环境的正常运行。故根据上图的流程下面对持续交付过程中操作进行分析。
分析与拆分
软件开发是一个团队合作的工作。在图中由相关的人员做相关的推动之后功能才能进入到下一个步骤。每一个步骤都可以将动作分为：构建、部署、测试和发布。而每个步骤所做的内容也有所不同，下面以步骤和环境例举要做哪些操作:
| 步骤 | 构建 | 部署 | 测试 | 发布 |
|---|---|---|---|---|
| 开发集成 | 编译 代码扫描 单元测试 |
简单部署 部分环境部署 |
开发测试 | 推送到测试环境 |
| 团队间协作 | 编译 自动接口测试 |
无部署 mock服务器 |
接口测试 | 将接口模拟发布 |
| 交付测试 | 编译 自动验收测试 |
全环境部署 | 自动回归测试 | 推送到用户验证环境 |
| 交付运维 | 编译 | 容器部署 负载节点 |
升级脚本验证 release notes验收 |
推送到正式环境 |
| 正式上线 | 编译 构建容器 |
容器部署 负载节点 |
无测试 | 允许回滚 |
对上面的操作进行拆分后，可以分为对资源的管理工作：
- 二进制包
下载代码、依赖管理、编译、打包、代码扫描、单元测试 - 容器
构建、发布、拉取、运行 - 部署
架构即代码、蓝绿发布、回滚
设计原则
前一段时间写了一篇分层架构模式，这里以分层的方式去说明部署流水线的分层关系。这里的分层其实是理解或概念的层面。这里将分部署流水线设计分为几个层次：服务层，流程层，原子操作层。
服务层
提供自定义能力，可以将流程和原子操作组合成一个适用于当前业务系统的。这个是最顶层，最实用的实用层。流程层
提供一整套流程提供各种各样的流程。大到可以将整体持续交付写到一个Pipeline内，也可以只对容器构建，发布过程形成一个Pipeline。只要之后可以用流程去组织各种各样的大的服务。原子操作层
提供最基础的原子操作。这里可以将上面提到的对资源的操作作为一个原子操作。不需要划分的更小。
总结
最好的实践，是在有大量项目的情况下去实现原子操作和流程层，然后在这两层上去实现具体项目的服务。如果产品型公司，比较好的方式是直接实现流程层和服务层。这样既可以满足业务要求，也可以降低流水线构建的成本。
