杜铁绳：DevOps场景案例

在软件研发过程中，首先需要考虑如何正确地将软件研发出来，并保证质量达标。随着软件行业的发展，市场需求变化也随之增大，有时发现研发出来的软件不符合市场预期，也不符合用户的使用需求。尽管团队投入了大量的精力与资源，软件的质量很高，但发布以后没有用户认可，现实与期望背道而驰，不仅打击了团队的积极性，也影响整个团队成员的绩效。

因此，从研发项目的角度来说，软件研发不但要做一个质量高的软件，同时也要符合市场预期，这才是一个正确的软件，这也是研发效能关注的重点。

据相关统计，很多软件的研发过程是失败的，其中延迟或无法交付、超出预算的占比42%，不符合市场预期而取消项目的占比21%，因研发方法不当导致软件研发无法进行的占比30~50%。因为有大量研发失败的情况存在，所以推出了很多方式来提高软件研发的正确性与成功率。DevOps作为一种优秀的方法论，其好处就是能加快软件研发的交付效率。

从研发效能的目标来说，很多科技公司会面临一个问题，到底是技术引领业务还是技术支持业务？

在很多情况下，业务和技术是分不开的，业务的实现依赖于技术的支持，同时技术的革新也会引领业务的变化。在研发效能方面，不同公司面临不同的目标，互联网公司的技术在引领业务发展过程中有很重要的作用，DevOps发展成熟度相对更高。而传统企业DevOps发展有所选择，有些业务方向会采用传统的方式来推进DevOps，比如会引进部分能力，而不是将其作为研发过程的核心关键要素。

在DevOps引入过程中，不管是引领业务还是支持业务，都要基于当前公司的现状来评估。不同行业的不同企业，其现状、团队能力、技术结构、基础设施与企业目标等不尽相同，因此在引入DevOps过程中会涉及工具和方法的选择。

举例来说，互联网公司的思想和吸收新工艺的方法相对更积极，所选择的应用场景也没那么复杂，所以DevOps的引入相对更理想，其智能化的程度也会更高。而相对传统的金融公司，团队成员的知识栈和技术会相对保守一些，在引入DevOps时要接触很多新的技术和工具，会面临很多新的挑战。

比如，很多Java项目没有采用微服务、容器化，只是基于虚拟机或物理机的传统部署方式，这时引入DevOps就会给团队增加很多转型的工作量，比如从0开始为团队建立代码库、选择代码管理工具、建立代码分支策略等等。选择的新工具与新技术越多，对原有的开发进展就会造成越大的影响。

所以在DevOps导入过程中，需要进行慎重考量，如何在开始阶段导入更平滑一些，减少对团队业务开发的影响，加强团队与导入工作的配合度，保证导入效果。其中会涉及一些方法和工具落地指导原则，比如方法和工具先进性与适用性相结合、先进性与风险相结合、难度与人员的适配、可获得性、成本和收益以及对交付连续性的影响，等等。

方法选择

DevOps导入过程有很多方式需要考虑，比如项目管理的方式，通常分为敏态和稳态，传统的瀑布开发方式就是稳态的方式，现在的Scrum、XP等是敏态的方式，不同的方式对软件交付有不同的影响。在金融行业中，很多业务的交付非常明确，每个阶段的交付进度基本都能预期到，这时不管使用哪种方式都不会造成明显影响，反而在导入过程中可能会对团队造成负面影响。因此，需要综合评估使用哪种方式对整个软件项目交付更有利。

在软件研发过程中还有其他一些技术的引入，比如最近比较火的TDD（测试驱动开发）、BDD（行为驱动开发）和DDD（领域驱动开发），在DevOps引入过程中都是互相支持的。

在很多项目中，DevOps从需求到交付是全都打通了，开发管理方式与DevOps也是融合在一起的。从DevOps功能来讲有很多维度，比如DevOps平台如何做需求管理分析、源码管理、统一可信源制品管理等等。另外还有软件质量中的左移和右移、监控部署、不良反馈等，在DevOps引入中都是需要考虑的。

整体规划

在DevOps落地过程中，软件研发需要一个面向全生命周期管理的整体规划。

需求管理，很多商业和实践工具都支持代码与需求相关联，每次提交代码都能看到对应的需求，这样开发人员和需求人员就能形成较好的沟通，了解提交的代码针对哪个需求，更清楚地展示活动效果，同时良好的需求管理也会促进后续软件开发过程的活动。

开发管理，用户故事梳理、开发任务拆分及状态跟踪可以让开发人员更清晰地理解用户的产品需求，可以与产品上下游进行更好的沟通，帮助开发与产品人员更好地协同工作。

测试管理，开发跟测试如何系统工作，涉及DevOps过程中的快速交付，其中的核心保障就是软件质量达标，否则无论部署CI/CD的效率多高，其他工作效果都是零。在DevOps工作流程中，测试是很重要的一个环节，尤其是自动化测试相关的保证，可以提高DevOps活动的质量与效率。

缺陷管理，涉及缺陷分类、提交、分配、修复验证、关闭等，在测试过程中正确管理缺陷，一旦发现缺陷以后就应该终止流水线，让开发人员去修复，否则既会浪费时间也会影响效果，所以需要通过质量门禁和测试缺陷的综合管理来提升构建的质量。

发布管理，包含发布清单、发布申请、发布审批、发布执行、回滚策略等。无论是开发还是测试的发布都需要考虑发布的不同环境，在协议过程中，环境的一致性要求DevOps有很高的敏感度。我们在传统开发模式下经常会遇到，在测试环境中软件没问题，但是在生产环境中有问题，这可能是环境依赖或环境参数导致的。所以在DevOps过程中，需要考虑环境的问题，以及发布流程的规范要求。

故障管理，包含故障反馈、故障分类登记、故障分配、故障原因分析、故障处理、故障验证、故障关闭等。即发布完成以后，生产上的问题如何去处理也是在DevOps过程中需要考虑的。

DevOps工具链

DevOps工具链，我们内部称之为基于研发生命周期的管理平台，在每个阶段通过相应的工具来提高效率，其核心就是DevOps，是拉通了需求到部署的整个过程。

在DevOps导入过程中，很少有公司是从0开始创建工具，多数情况下是已经使用了某些工具，只是需要通过DevOps将这些工具进行更好的规划，以便在整个体系中发挥更大作用，让工具链的上下游更好协作，数据更好流转汇集，形成对研发管理有价值的信息流，这是在规划DevOps工具链过程中需要考虑的。

技术栈和工具链举例：

DevOps建设不是一蹴而就的，需要基于实际情况去逐步迭代，在迭代过程中用好相关的技术工具，减少DevOps过程中工具的重复开发，提高开发效率。同时，高效明确的规划路径可以让团队和领导对DevOps过程产生信心，有利于DevOps建设成功。

分层测试

前面提到在DevOps过程中需要做很多质量保证，其中涉及到一些测试的模型，如分层测试。

在安卓客户端、iOS客户端和Web前端与客户建立交互的都是UI层的相关测试，UI层测试有不同的技术框架和技术方式，需要开发团队或测试团队有相关的技能去实现智能化测试，才能在DevOps流水线中很好地实现验收。

越靠底层，其技术选择方式越多，像基于接口、单元的测试，对开发和测试团队都有很多要求，实现了基于不同层面的自动化测试，才能很好地保证CI/CD过程中的软件质量和自动化，更高效交付高质量的软件。

DevOps与BDD

DevOps的演进需要产品和开发的合作，期间需要通过团队去梳理、表述用户故事，然后用智能化技术更快实现软件的验证。前面提到BDD（行为驱动开发），这个过程其实就是产品和研发团队如何更好地配合以快速交付产品，并更快地验证。

简单描述一下BDD的思想，首先产品跟开发和测试团队同时讲述一个用户故事，比如用户想取一笔钱，然后输入密码就能从取款机取到钱。描述完场景后，开发人员将场景做一些设计架构和开发，之后业务开发公司要对其验收，即开发人员做到什么程度、满足哪些事项可以认为开发工作完成。讨论完以后，开发人员开始开发工作，测试人员同步做一些自动化测试的交付和案例，开发与测试人员配合进行功能的验证，通过则业务场景完成开发，否则继续修改直到通过为止，这是BDD的执行过程，也是DevOps过程中优秀的软件工程实践。

自动生成报告

DevOps工具通常会自动生成报告，从多个方面对每个应用场景生成一些统计，展示每个步骤的通过率、耗时等，有时互联网应用有大量的用户在使用，每一步耗时的增加可能会导致资源的消耗增大，若能知道每一步是否符合预期就能更好帮助开发人员做程序的性能调优，在验收时就能知道软件的性能。同时，通过报告能了解到每个步骤的失败率和验收效果，可以让需求人员、开发人员等不同角色能够形象地知道整个验收效果。

持续度量

持续度量，就是从需求质量到交付质量的整个周期中，将每个阶段要做的事、出现的问题、发生的结果等进行可量化的记录展示，分析评估其中的不足。

团队成熟度指标是团队比较关注的，比如需求量、源码量、代码质量、测试效果、团队质量等度量指标，通过数字化统计传达给团队领导和公司领导，展示团队的度量构建效果。

还有业务指标的交付，通常情况下领导们更关注研发团队实现了多少业务目标的交付，通过度量指标让业务侧和领导能清楚地知道整个业务价值交付的状态，是否需要调整资源的投入。

同时还有效能指标的展现，即研发的效率如何，比如不同阶段的度量指标分布情况、CD的效果、研发运营一体化的生产评估等等，会有诸多的指标来衡量现在DevOps所处的阶段，是否能很好地完成交付任务，达到公司领导的预期，这也是DevOps整个度量过程中所关注的事项。