基于禅道设计的研发流水线，实际就是分为了两条流水线：CI和CD，CI流程就是产出最终可交付至线上的版本制品，CD流程就是将CI产出的制品最终交付至线上。在流水线执行过程中，约定了各个版本环境，如：Dev环境、IT环境、ST环境、UAT环境、PVT环境、GVT灰度验证环境、MVT量产环境等。
1 流水线设计
按照devops理念，整个开发及发布流程被设计为两条流程：持续集成和持续发布。
在这里持续（continuous）的概念，包含的意义是：
1、流程可以反复执行；
2、流程是由多个子流程组成，流程之间都是前后顺序连接，持续执行的。
由于我们的核心构建系统采用的是jenkins，所有流程的实现是采用的jenkins中的流水线pipeline脚本来实现的。
最终实现的结果就是持续交付系统主要有两条流水线：
-
版本持续集成（CI，Continuous Integration）流水线
就是对源代码进行构建，生成版本制品的过程。 -
版本持续发布（CD，Continuous Delivery）流水线
就是将经过测试之后合格的版本制品发布部署到目的地的过程。
我们设计的CI和CD流水线的概图如下：
2 持续集成流水线（CI, Continuous Integration）
下面是一个一般的CI的流程模型：
3 持续发布流水线（CD，Continous Delivery）
下面是一个一般的CD的流程模型：
4、版本和环境流程图
在逻辑意义上来说，我们目前做了如下定义：
- 环境是一个逻辑概念，在物理上的实现，它就是从物理集群内启动并运行起来的一个docker容器；
- 内网开发集群定义了系统集成测试环境（SIT，System Integration Test environment），支持的环境数量为三个：sit0、sit1、sit2。
- 内网测试集群定义了用户验收测试环境（UAT，User Acceptance Test environment），支持的环境数量为三个：uat0、uat1、uat2。
- 生产集群，不管是内网还是外网，公有云还是私有云，都定义如下三个环境：
- 预发布环境 pre-release
- 灰度发布环境 grey verification environment
- 正式生产环境 mass production
5、测试环境域名管理方案
目前测试环境的访问方式主要有两种，这两种方式可以同时使用：
-
1、不同环境不同域名方案
部署至不同集群环境，生成不同域名方案。
如：域名为"demo.com"，部署至sit0环境，则自动生成域名"sit0-demo.com"
-
2、不同环境同一域名方案
部署至不同集群环境，访问客户端通过**
域名代理**访问同一域名（多环境同域名方案OpenResty方案: Nginx+lua + redis 实现根据访问者IP将访问请求转发到对应环境，并能对IP与环境的绑定关系进行管理（方案详情参考此文，多环境同域名设计），访问至不同集群环境。如：域名为"demo.com"，通过域名代理将访问客户端IP与目的访问集群入口域名"sit0-demo.com"绑定即可实现同一域名访问。