对DevOps流水线设计的优化和改进实践( 四 ) 对于DevOps过程支撑平台

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

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

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

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

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

测试对需求进行验证，并提交Bug ，测试人员修改Bug并触发流水线重新构建

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

在UAT环境的验收测试同样的道理

在UAT环境所有问题也验证关闭后，进入到正式发布生产环境。

流水线设计属于持续交付过程域中的一个关键内容，其核心还是为了持续集成服务。简单来说就是流水线作业解决自动化的持续集成问题，那么持续集成本身又包括哪些关键内容？
即我们常说的自动化编译构建，自动化部署，自动化测试。而在转到和容器技术结合后可以看到在编译构建完成后自动化部署进行了拆分，即部署动作变化为了首先是自动化的打包即制作容器镜像，然后才是自动化部署，部署部署基于部署包的，而是基于制品库中的容器镜像的。
可以看到，在DevOps中的流水线设计更多的是解决开发人员的自动化问题，即开发只需要check in自测通过的代码到配置管理库，那么后续的所有事情都自动化完成，最终部署到测试环境供测试人员测试。
开发人员不用关心编译构建过程，不用关心测试服务器包括测试环境数据库，中间件的安装部署等一系列的问题。同时由于一系列的自动化操作，也让代码从检入到交付测试的周期缩短了，在周期缩短后交付频度也可以进一步提升以加快迭代速度。
对于DevOps支撑平台我们一直在谈流水线自动化设计，但是更应该反过来谈持续集成方法论和最佳实践，因为流水线设计仅仅是为持续集成和持续交付服务的工具链而已。其次，对于当前流水线设计，更多是从技术层面开发人员自动化在谈，但是却少考虑研发管理开发和测试过程协同问题。
在DevOps最佳实践里面分为了研发管理，持续交付和技术运营几个关键的过程域。但是在实践的过程中，最容易出现问题的不是单个技术点，而是跨域的协同问题，或者说研发过程管理和持续集成交付本身就是密不可分的两个部分，我们只是为了容易理解和学习将其划分为了不同的过程域而已。
研发过程管理和持续集成间的协同关系

文章插图
要明白任何一次新的编译构建部署完成后都涉及到测试人员测试，测试人员测试出问题后又会提交Bug ，开发人员修改Bug后check in代码，等待下一次打包部署以形成多次迭代。
整个过程最好方式就是要尽量减少大量的人工沟通协同，而是应该通过工具链协同来完成。
对于传统的持续集成，一般最佳实践为每天晚上进行自动化构建和冒烟测试，而对于当期的DevOps过程，在设计完流水线后，可以手工去启动流水线作业，也可以自动去执行流水线，或者代码库变更后实时触发流水线执行。流水线执行时间频度也可以进一步缩短，假设我们每2个小时自动化的执行一次流水线作业，我们以此场景来做进一步梳理。
流水线增加启动检查节点
虽然2小时执行一次流水线，但是在执行前先进行启动前检查，如果在最近2个小时内没有新代码check in ，那么不执行流水线。其次，如果上一次流水线执行实例还处于待处理或未关闭状态的时候，同样也不执行流水线作业而直接跳过。
是否需要人工验证节点