持续交付和DevOps流水线(8.8)

最近在思考DevOps流水线的时候，发现我们实际的流水线设计往往都是开发编译构建流水线，编译构建并发布流水线，单独的生产环境发布流水线等，而很少看到有将多个环境迁移编排到一个流水线的设计思路。同时根据DevOps持续交付的最佳实践，好像也不推荐将多环境迁移编排到一个流水线作业里面。

对于该问题，我们还是要回到我们在最早持续集成中面临的业务场景出发进行思考。特别是涉及到DEV，SIT，UAT和生产等多套环境的时候，自动化的环境迁移是一个很重要的业务需求。在这个过程中项目有一个本次研发的版本号，同时针对每一次编译和构建形成一个构建版本号，注意项目版本号将正贯彻整个持续交付过程的一个关键追溯主线，包括环境迁移，生产环境的发布都必须围绕项目版本号主线展开。

我们重新思考下整个持续交付的过程应该如何

1. 基于收集到的用户需求整理后形成软件需求，进行版本规划，纳入本次版本要处理的需求和Bug

2. 规划一个新的项目版本好，后续的项目需求，任务，缺陷管理等也都基于该版本号进行

3. 开发可以构建一个流水线，完成编译，构建，代码检查，发布，自动化单元测试，对应Dev环境

4. 开发应该在对发布到Dev环境的功能再做一下自测（手工节点）

5. 开发在自测没有问题的时候，应该自动的将该部署包迁移部署到SIT环境

6. 开发人员将对应的需求或Bug转到待测试验证状态（或者说应该自动的进行处理）

6.1 做法一：开发提交一个测试申请单，关联可以进行测试的需求或Bug

6.2 做法二：开发在处理自测节点的时候，手工关联可以进入下一步测试的需求或Bug并提交

7. 测试人员只需关系待测试验证的需求，这个时候在SIT环境的版本一定是部署好可验证的版本

8. 测试人员对需求进行验证，并提交Bug

8.1 测试人员在Bug验证完成后，如果没有全部测试通过，不做后续处理

8.2 开发在收到测试问题后，应该可以重新触发流水线编译构建操作，并重新发布新构建版本

9. 测试人员在所有缺陷全部验证通过后，确认集成测试通过环境，版本自动迁移发布到UAT环境

10. 在UAT环境的验收测试同样的道理，有问题不做后续处理，有Bug提交Bug并重新触发构建

11. 在UAT环境所有问题也验证关闭后，进入到正式发布生产环境。对于生产环境发布可以单独构建流水线

对于生产环境发布来讲，它不是一个需要多次重复的操作，而是应该将UAT测试通过的版本发布并部署到生产环境上，因此生产环境发布涉及到版本提取，自动化部署(应用+数据库），发布后验证。没有问题就结束。对于可以提取的版本都应该在前面编译构建测试流水线走到最后的测试通过的版本。这些版本可以做为生产环境正式发布的时候的提取版本。

如果版本发布对应到客户生产环境，也可能客户生产环境没有进行容器化，那么版本提取功能要支持直接提取部署包文件，部署脚本文件，这些部署包和部署脚本参考部署手册在客户现场进行手工部署。我们可以看到客户现在部署的版本是打包编译构建完成的二进制文件包，这个部署包经过了多环境迁移和验证，是一个经过充分确认的版本。

在DevOps实践中，一定要解决好的就是开发和测试的协同，开发测试和工程运维的协同。因此对于研发项目过程管理工具，DevOps支撑工具本身要紧密集成才能够更好的支持整个协同过程。虽然敏捷方法论强调面对面的沟通，但是在整个持续交付过程中要减少各种无谓的沟通，通过工具进行自动化协同。类似测试不清楚开发的功能是否完成了，是否可以测试了，是否部署到SIT环境了，Bug是否修改好可以重新验证了等等问题，都应该在工具层面进行解决。

开发和测试协同：重点是解决版本多次编译构建持续集成和测试验证过程协同

开发和运维协同：重点先解决测试形成文档可发布版本后的，工程运维进行版本提取和部署的协同

一个软件产品本身在设计开发的时候就应该考虑可运维，可监控的属性，这个在DevOps成熟度模型中的技术运营有专门的描述，这个是需要开发和运维的第二个层面关键协同。运维人员也不再是简单的主机和环境的运维人员，而变化为实际的应用运维和监控人员。

下一篇要准备谈下微服务架构本身和DevOps持续交付的集成，这个实际上在博客前面很多文章里面都已经谈到过，只是结合总最近的实践重新进行思考和整理。