当前位置：首页 > DevOps > 正文

DevOps建设的思考和实践

2020-03-02 来源：有赞技术

了这样一番触目惊心的景象：

1.3 集成周期

由于研发是一项需要多方协同的工作，而各方的产出成果非常明确：符合产品功能和质量预期的代码。关于这个结果，在研发前期筹备时，各方按产品功能点目标进行任务分解时，就已经注定了的。既然是为了共同的产品目标，大家齐头并进，分别进行研发生产后，就必然要将成果汇合到一起，以产生协同创新的价值。我们通常诟病瀑布项目模式最致命的缺陷之一，就是每个人开发质量都很高，但大规模集成时就一塌糊涂。

所以，研发人员需要不断尝试与上下游进行集成，而集成又涉及到代码的编译运行，每次集成都是一场等待，对项目来说也是一次煎熬，时间进度难以控制，故精益认为这是一种「等待」的浪费。尽管我们在项目流程中定义了「接口先行」的管理动作，但在实际编码过程中，还是会随着对需求产生进一步理解和澄清后，研发人员随手变动接口（但没有及时通知上下游）的情况。下图是有赞 DevOps 平台关于某一应用的时效情况：

二、效能改进的切入点

2.1 理念导入

万事开头难。虽然研发团队对在业界如日中天的「开发运维」已有一定的认知，但重点关注放在工具的运用上，目的是提升本团队的工作效率。而经过一系列尝试后，大家已经隐约意识到，「持续集成」才是在频繁交付的压力下提升研发效率的高杠杆点，而「规范单测」和「环境治理」是保障持续集成的前提，于是效能改进团队携手研发团队、质量保障团队和运维团队共同商议决定，将这两项工作进行深入宣贯。思考路径如下：

1）如果有足够覆盖率的高质量单测用例，就能保护业务代码的逻辑，在不增加额外测试成本的情况下，经得起任何变更和调整；

2）如果有健康稳定的测试环境，代码就能在被提交到代码仓库后，自动触发执行静态代码检查和单测用例，快速验证新增代码的正确性和健康度，经得起频繁交付下质量保证的考验；

3）基于单测用例，可以根据业务场景组合形成集成用例，在健康稳定的测试环境下，无人值守地持续进行集成，自动触发打包和部署，并验证业务逻辑，甚至发布上线（一般实践是发布到预发环境），

分享到:

免责声明：
　　1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
　　2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！

上一篇：
从微服务到人工智能：2019年DevOps的八大趋势
下一篇：
最后一页

延伸阅读：

more 会议活动

more 公开课

more PMO

微信扫一扫关注

DevOps建设的思考和实践

延伸阅读：

会议活动

公开课

PMO

IT项目管理界官方微信

PMO大会官方微信