持续集成与持续发布流程

前言

之后的工作中会负责版本控制与发布，所以根据现有的逻辑整理一下持续集成与发布的流程。
首先，持续集成，持续发布，这个概念通过这篇文章有个大致的了解https://yq.aliyun.com/articles/72400
自己总结了一下，对于传统的开发模式，一般使用的代码管理工具是svn，svn放置于一台服务器中，每次从svn中down下来最新的代码，修改后上传到服务器。但是若大幅度提交导致服务器挂掉，会导致代码的缺失等问题；另外，传统的开发模式，多数在开发完成之后，再进行测试，测试通过一轮手工测试后，部分公司会在上线前进行一轮回归测试。
这样的问题，显而易见，项目周期延长，人力成本过高。

流程

一张图片来看一下，现在的工作流程：
首先，分为3个环境：
集测环境：代码递交–静态检查—单元测试–接口测试等
预上线环境（灰度发布）：在registry节点打包—生成image镜像，利用上线环境数据测试–接口测试、性能测试等
上线环境：使用预上线环境的image

开发阶段

1.团队成员工作在develop分支上，develop分支只允许提交将在下个版本发布的代码
2.提交到develop分支的代码要求是可以工作的代码，不能导致代码构建失败
3.Jenkins监控develop分支代码更新，进行docker镜像构建，并更新到集测环境，产品经理可以在集测环境看到最新的开发进展
4.对于不在下一个版本发布的特性，应fork独立的feature/xxx分支进行开发，在下一个release/x.x版本fork之后再merge到develop分支

预发布

1.预发布条件：develop分支已经包含本次发布的所有特性，且集测环境验证通过，进入预发布阶段
2.假设待发布的版本号是： 1.0，从develop分支fork出release/1.0
3.使用Jenkins的yuce_release项目生成构建，填写本次构建的版本号：1.0，构建生成待预发布的docker镜像
4.进入预发布环境，同步生产数据库到预发数据库，按需升级预发数据库（可选），使用预发布的docker镜像更新预发布环境，进行预发布环境的验证测试
5.验证测试期间，若发现bug，则在release分支上进行修复，并将改动merge回develop分支，重复3-4-5

发布

1.发布条件：团队成员确认预发布环境验证通过，进入发布阶段
2.进入生产环境，备份生产数据库，按需升级生产数据库（可选），使用预发布验证过的docker镜像，更新生产环境，进行生产环境的验证测试
3.团队成员确认生产环境验证通过，至此本次发布完成

另外以上基于自动化测试很完善的情况。在没有自动化测试时，很难做到对质量的控制。目前企业级比较认可的覆盖率是75%左右。其次是看漏测率，有时候自动化用例本身也可能有Bug，前期阶段通过比较手动测试自动化测试的结果来判断自动化测试是否有效。（–引自熟悉概念的那篇文章）

所以，自动化测试方面，任重而道远