再谈DevOps流水线设计(10.10)

对于DevOps实践中的流水线设计在我博客前面很多文章都谈到过，今天要再拿出来做下分析，
流水线设计属于持续交付过程域中的一个关键内容，其核心还是为了持续集成服务。

那么我们首先回顾下流水线作业解决什么问题？简单来说就是解决自动化的持续集成问题，那么持续集成本身又包括哪些关键内容？即我们常说的自动化编译构建，自动化部署，自动化测试。而在转到和容器技术结合后可以看到在编译构建完成后自动化部署进行了拆分，即部署动作变化为了首先是自动化的打包即制作容器镜像，然后才是自动化部署，部署部署基于部署包的，而是基于制品库中的容器镜像的。

说这么多，可以看到，在DevOps中的流水线设计更多的是解决开发人员的自动化问题，即开发只需要check in自测通过的代码到配置管理库，那么后续的所有事情都自动化完成，最终部署到测试环境供测试人员测试。开发人员不用关系编译构建过程，不用关心测试服务器包括测试环境数据库，中间件的安装部署等一系列的问题。同时由于一系列的自动化操作，也让代码从检入到交付测试的周期缩短了，在周期缩短后交付频度也可以进一步提升以加快迭代速度。

今天再谈流水线设计，主要的原因是，对于DevOps支撑平台我们一直在谈流水线自动化设计，但是更应该反过来谈持续集成方法论和最佳实践， 因为流水线设计仅仅是为持续集成和持续交付服务的工具链而已。其次，对于当前流水线设计，更多是从技术层面开发人员自动化在谈，但是却少考虑研发管理开发和测试过程协同问题。

在DevOps最佳实践里面分为了研发管理，持续交付和技术运营几个关键的过程域。但是在实践的过程中，最容易出现问题的不是单个技术点，而是跨域的协同问题，或者说研发过程管理和持续集成交付本身就是密不可分的两个部分，我们只是为了容易理解和学习将其划分为了不同的过程域而已。

今天继续谈流水线设计，还是想进一步理清研发过程管理和自动化持续集成间的协同关系。

要明白任何一次新的编译构建部署完成后都涉及到测试人员测试，测试人员测试出问题后又会提交Bug，开发人员修改Bug后检入代码，等待下一次打包部署以形成多次迭代。整个过程最好方式就是要尽量减少大量的人工沟通协同，而是应该通过工具链协同来完成。

对于传统的持续集成，一般最佳实践为每天晚上进行自动化构建和冒烟测试，而对于当期的DevOps过程，在设计完流水线后，可以手工去启动流水线作业，也可以自动去执行流水线，流水线执行时间频度也可以进一步缩短，假设我们每2个小时自动化的执行一次流水线作业，我们以此场景来做进一步梳理。

流水线增加启动检查节点 -虽然2小时执行一次流水线，但是在执行前先进行启动前检查，如果在最近2个小时内没有新代码check in，那么不执行流水线。其次，如果上一次流水线执行实例还处于待处理或未关闭状态的时候，同样也不执行流水线作业而直接跳过。

是否需要人工验证： 流水线打包部署包括两个方面，一个是新功能提交或新bug解决，只有这种情况才需要人工验证。因此一次流水线执行如果没有新需求或Bug状态变化，那么应该直接跳过人工验证节点并关闭。反之，则应该跳转到待人工验证环节。

需求和缺陷的管理： 注意新需求和新缺陷都应该提交，都有状态，需求细分到具体的需求功能点，同时测试人员提交的缺陷应该对应到具体的需求功能点上面。一个需求开发完成后，需求本身也到待验证状态，但是一个待验证的需求是否能够关闭则必须是改需求下面所有的bug都解决完成后才能够关闭。

需求和缺陷状态的变化： 开发人员首先是将需求或缺陷完成，并在本机进行自测通过，然后将代码check in到配置管理库。同时手工将需求或缺陷状态处理到待部署状态。在流水线启动后，如果整个构建打包和部署成功，则在成功完成应用部署后，将待部署状态的需求或bug转到待验证状态。在部署完成后测试人员可以看到待验证的bug或需求，那么他进入当前的测试环境一定是最新的可以进行缺陷验证的环境。

应用部署和环境迁移： 实际上我一直在思考如何理清这两者的关系，包括在流水线节点设计的时候是同种类型的一个节点还是不同的两个节点？应用来说是直接将编译打包后的镜像执行进行部署，前面有编译构建操作；而对于环境迁移来说则是直接从制品库里面使用已有镜像进行环境部署。

流水线模板和流水线实例应该是两个不同的概念，一个流水线模板每次运行都会产生一个实例，而每次实例都会形成一次构建版本号。即每次打包后形成的镜像入库也会附带上这么一个流水线实例号。那么我们的应用部署操作本身就简单的，对于应用部署活动节点编排在流水线上面，作用是进行应用部署，但是本质是从制品库拿到对应镜像去部署？如何拿到对应镜像，基于流水线实例号就可以很好的进行对接上。

从SIT到UAT环境： 在环境迁移中，我们设置两个环境，一个SIT环境供内部测试人员测试，一个UAT环境供客户方进行UAT测试，那么在SIT测试完成后可以将SIT环境的镜像包迁移到UAT环境进行部署。那么并不是每一次流水线作业都涉及到环境迁移操作，而实际上需要测试人员去判断当前的测试版本是否需要迁移到UAT环境去供用户测试。同时测试人员在当前测试问题全部修复并关闭后可以对当前版本打配置基线操作。其次，对于用户测试提交的问题一般并不会在我们自己的缺陷管理系统进行Bug记录，因此用户反馈问题给测试人员，测试人员帮忙录入到缺陷管理系统，同时缺陷修改完成后测试先要验证没有问题，再通知用户进行验证，只有用户验证通过后缺陷才能够最终关闭。