流式开发模式下的DevOps实践

2233夜不归宿的研发人通宵发布通宵发布效率低下效率低下迭代开始没需求迭代开始没需求发布忙发布忙无内建质量无内建质量事故频繁事故频繁小BUG大事故小BUG大事故环境不一致环境不一致运维监控缺失运维监控缺失单体->微服务复杂性提升效率和质量单体->微服务快速响应用工作的正常化复杂度的简化持续改进提升效率和质量单体->微服务快速响应用工作的正常化复杂度的简化持续改进为什么是Mars温饱问题温饱问题发展问题发展问题Mars0.12015.10Mars1.02019.6Mars3.02020.08MarsMars0.12015.10Mars1.02019.6Mars3.02020.08Mars0.52017.6Mars2.02020.2持续交付、灰度微服务流水线、多泳道、灰度发布工具化微服务持续交付单体&微服务2233并行工作并行工作方式流式特性流式特性需求开发周期性迭周期性迭代发布）（线下步骤创建特性分支(f-/bg-)构建功能集成测试环境构建预发布测试环境环境g0/g1并入特性分支测试人员Jinkens构建署创建开发分支(dev-f-/dev-bg-)环境G2↓线下步骤创建特性分支(f-/bg-)构建功能集成测试环境构建预发布测试环境环境g0/g1并入特性分支测试人员Jinkens构建署创建开发分支(dev-f-/dev-bg-)环境G2↓开发人员功能代码↓标记测试通过!代码审核代码扫描功能集成测伸缩标记测试通过功能开发分支并入特性分支预发布测试环境G2!标记测试通过功能分支并入集成分支流水线需求阶段开发测试CI功能测试CI预发布测试CI↓↓功能自测单元测试↓↓功能自测单元测试代码合代码合并后自动触发按发布计划部署上线直接发布!↓标记测试通过↓统计分析灰度发布按发布计划部署上线直接发布!↓标记测试通过↓统计分析漂移g0/g1全部漂移G2全部漂移G2迭代灰度分支生产分支f合并f合并迭代发布日 集成预发布测试灰度发布创建创建集成测试当日灰度发布灰度发布创建创建集成测试当日开发测试迭代发布时合并到开发测试开发测试下次迭代发布到合并到MasterGray下次迭代发布到合并到MasterGray 创建创建集成测试Bg-1发布集成测试Bg-n发布 合并开发测试开发测试双主干分支模型说明：双主干分支模型说明：2、特征分支：bg；Release；Master;3、并行开发、并行测试；4、每天（随时）串行发布；5、对应灰度生产环境：G1、G2；双主干分支模型说明：MarsterGray灰度主干：1、需求类型：日常迭代需求；2、特征分支：f；ReleaseGray；MasterGray;3、并行开发、并行测试；4、迭代双周并行发布；1、并行需求处理：支持日常迭代需求、紧急需求、BUG的并行处理；2、发布周期不同：日常迭代需求的迭代周期为2周，紧急需求、BUG的迭代周期为1天；3、双主干的代码同步机制：迭代发布时，进行双主干分支代码的同步；4、分支删除时机：f、bg特性分支在发布到生产环境时才删除；5、多泳道支持：测试环境支持多泳道，合并多个特性分支支持多分支合并的泳道测试；6、灰度环境：支持迭代灰度环境G0、BUG灰度环境G1、正式生产环境G2环境的灰度；Mars灰度-为什么要灰度小BUG大事故；研发为客户快速、高效、稳定的交付产品；分支分支合并分支构建部署构建部署G0（20%）灰度发布G0（20%）灰度发布灰度环境生产环境灰度环境生产环境通过灰度、回滚、自动化降低发布风险、提升系统可用性步骤图例背景介绍：迭代需求灰度&紧急需求灰度集成回归：确保所有紧急需求都已上线，进行迭代集成回归测试；发布BUG：迭代过程中的BUG，直接基于Marster修改，不影响正常的迭Mars灰度-带来了什么•大需求隔离（长时间的开发、测试）•多测试协作（独立测试，并行测试，降低影响）•灰度（未来更多的畅想）Mars多泳道-解决方案、如何节省成本1.设置test-hl-bff-llllservice指向envoypod2.envoypod里面设置代理规则，根据trace-branch测试每日发布迭代每日发布到G0、紧急需求发布到G1支撑实践：流水线、分支模型、灰度发布、多泳道、灰度发布日发布到G22233持续集成之内建质量度量技术架构自动化测试p内建p意识代码质量开发运维一体化麦思博(msup)有限公司是一家面向技术型企业的培训咨询机构，携手2000余位中外客座导师，服务于技术团队的能力提升、软件工