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