由于devops没有统一的标准，关于devops应该做什么也没有严格的限制。个人认为，应该遵守unix小而精的做法，提供一批小工具，细致实现，组合使用。粗略设计可以提供5种工作流
1.部署到开发环境（push to dev）
部署到开发环境的目的就是为了调试，所以希望快速部署，并且开发环境运行时可以打印更细致的日志，甚至可以原地修改代码查看效果。由于网络隔离等等其他的原因，编码机器和开发环境共存还是有必要的，这个需求一般存在于开发者个人的私有分支
when：提交推送代码触发
输入：指定分支，分支必须已经存在
输出：更新服务或者失败提醒
- step1: 更新代码
- step2: 编译构建
- step3: 重启服务
2.单元测试（unit test）
部署到开发环境时，追求快捷，一般跳过单元测试。这个需求一般存在于团队的开发分支，该分支尽量别推送提交，只接受mr
when：接受mr后触发
输入：指定分支，分支必须已经存在
输出：测试报告
- step1: 更新代码
- step2: 单元测试
- step3: 质量检查
3.构建制品（build artifacts）
制品应该可以追溯到原来的代码。正式环境部署时，应该强制使用制品部署。制品发布之前，应该进行周密的测试。
when：推送Tag时触发
输入：指定Tag，tag必须已经存在
输出：制品+测试信息
- step1: 拉取代码
- step2: 单元测试
- step3: 质量检查
- step4: 构建制品推送到制品仓库
- step5: 测试环境部署
- step6: 自动测试
4.制品发布（artifacts release）
制品有很多种传统包（pip包，yum包，apk包）和docker镜像，传统包存在于构建的机器上，docker镜像位于构建机器的docker服务中
when：人工手动触发
输入：制品+测试环境访问
输出：制品签名
- step1: 人工测试通过
- step2: 制品签名
5.安装部署（deployment）
安装部署可以作为完整服务的子模块的调度单元，基于此编排设计完整的部署方案。
when：人工手动触发
输入：制品仓库的制品+目标环境信息
输出：安装部署结果（安装部署操作是幂等的）
- step1: 检查制品签名
- step2: 将已经签名的制品部署到目标环境
网友评论