在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记录，因此用户反馈问题给测试人员，测试人员帮忙录入到缺陷管理系统，同时缺陷修改完成后测试先要验证没有问题，再通知用户进行验证，只有用户验证通过后缺陷才能够最终关闭。