DevOps实践系列文章，请参见连接。

描述

在一个软件产品公司中，一般的基础设施会包括在每个产品线上的各种环境、以及针对这些环境构建起来的部署流水线。

• local：本地开发环境
• dev：内部开发环境
• mock：团队间协作时使用的模拟环境
• test：供测试人员测试环境
• performance：非功能需求测试环境
• stage：试运行环境（新功能部分目标用户使用）
• production：对外开放的产品环境

一个已经上线的正式产品，第一要务就是保证线上系统是稳定可靠运行的。所以需要通过各种手段保证新功能上线，线上系统问题的快速反馈与立即解决。根据不同公司产品形态的不同，每个公司都需要有一套功能上线流程以保证线上系统的正常运行。

上图中比较详尽的描述了一个功能从开发到上线的整体过程。且在过程中每一个过程都由不同的角色参与。最终保证系统在线上环境的正常运行。故根据上图的流程下面对持续交付过程中操作进行分析。

分析与拆分

软件开发是一个团队合作的工作。在图中由相关的人员做相关的推动之后功能才能进入到下一个步骤。每一个步骤都可以将动作分为：构建、部署、测试和发布。而每个步骤所做的内容也有所不同，下面以步骤和环境例举要做哪些操作:

对上面的操作进行拆分后，可以分为对资源的管理工作：

• 二进制包
  下载代码、依赖管理、编译、打包、代码扫描、单元测试
• 容器
  构建、发布、拉取、运行
• 部署
  架构即代码、蓝绿发布、回滚

设计原则

前一段时间写了一篇分层架构模式，这里以分层的方式去说明部署流水线的分层关系。这里的分层其实是理解或概念的层面。这里将分部署流水线设计分为几个层次：服务层，流程层，原子操作层。

• 服务层
  提供自定义能力，可以将流程和原子操作组合成一个适用于当前业务系统的。这个是最顶层，最实用的实用层。
• 流程层
  提供一整套流程提供各种各样的流程。大到可以将整体持续交付写到一个Pipeline内，也可以只对容器构建，发布过程形成一个Pipeline。只要之后可以用流程去组织各种各样的大的服务。
• 原子操作层
  提供最基础的原子操作。这里可以将上面提到的对资源的操作作为一个原子操作。不需要划分的更小。

总结

最好的实践，是在有大量项目的情况下去实现原子操作和流程层，然后在这两层上去实现具体项目的服务。如果产品型公司，比较好的方式是直接实现流程层和服务层。这样既可以满足业务要求，也可以降低流水线构建的成本。

参考

持续交付