前言
在11月召开的中国 DevOps 社区广州峰会上，无限极（中国）有限公司DIT开发与测试中心的测试与效能经理陈顺生分享了其团队在支持公司业务数字化转型中的 BizDevOps 建设实践，令在场听众受益匪浅。
一、背景与挑战
1. 灵魂三问
在工作中我们是不是经常听到这样几个问题？
"我的需求提交好久了，什么时候可以上线？"
"大家都说需求很急，排序怎么做合理？"
"大家很忙，但其他部门质疑我们工作量不饱和！"
第一个问题，业务部门关注客户需求并收集反馈给产研部门，却迟迟未能实现上线，询问进度时产研团队也无法明确承诺上线时间；
第二个问题，产品经理在面对一线业务提出的紧急需求时，无法权衡各个需求的价值，难以进行有效的排序和优先级设定，于是只能将这些需求传递给生产和研发部门；
第三个问题，研发团队的工作节奏常常被打乱，虽然看起来工作繁忙，但实际上效率低下。尽管其他部门也无法提供确凿的证据来支持他们的观点，但研发团队也难以拿出有力的证据来反驳这种状况。工作量的管理缺乏系统化的承载和度量方式，这使得生产和研发部门感到压抑和不满。
可见，业务、产品、研发三个角色各有痛点。无限极在业务指数式的爆炸增长下，引入 DevOps 前也面临着同样的挑战。于是交付效率的问题反复被提及，面临内部质疑，产研开始探索解决研发效能问题，证明自己。
2. 数字化转型过程中遇到的挑战
无限极在数字化转型中会经历三个阶段，分别是信息化、数字化与未来的全面智能化。在初期的信息化阶段，我们引入了数个单一工具以达成生产效率的初步提升，结果这些单一的工具形成了数据孤岛。到了基于云底座的数字化转型阶段，数据孤岛对数据闭环、分析造成了障碍。如果想实现数智化，数据孤岛也是需要治理的先决条件。
我们决心解决上述两类痛点与挑战，从组织文化、流程、工具、架构等层面进行改变。其中组织文化和人员技能就要求内部IT同学进行转变、并借助外部优秀的工具辅助提升效能，以满足快速迭代和交付产品价值。
二、 破局三板斧
破局？我们聚焦在三板斧！即敏捷文化宣导，组织流程优化、借助DevOps工具赋能以及技术容器化升级。这一切建立在数据层面分析驱动。
1. 打造数字化时代的高绩效研发组织
在组织文化和团队建设层面，以业务目标驱动，致力于打造数字化时代的高绩效研发组织，打破职能边界，转型为敏捷交付团队。
在实践过程中我们发现很多敏捷框架无法直接导入------在Scrum或LeSS里，PO的地位不上不下；Scrum Master 只是敏捷鼓吹手，不对交付结果负责，这与国内组织文化很不匹配。因此最终决定践行规模化敏捷框架ADAPT。
ADAPT框架包含5个部落级角色（部落长、业务负责人、测试分会长、架构师、版本经理），以及3个小队级角色（产品经理、小队长、研发小队成员）。部落可以是个虚拟组织，在不改变企业现有组织架构的情况下搭建而成。所以，这些角色定义的也可以是部落运行中的虚拟角色。
-
**业务负责人：**部落的业务带头人，覆盖产品整体范围和优先级决策。通常一块业务有一个负责人，对业务结果负责。当需求优先级发生冲突时，给出最终决策。
-
部落长：部落的交付负责人，负责部落交付和资源配置，也对部落最终绩效负责。部落长负责整合部落内的各种资源，保证快速高质量完成交付，也为跨部落资源协调提供帮助。
-
产品经理：部落产品创新的核心力量 。产品经理要能融合业务知识、互联网运营思维和科技能力，综合要求较高，通常需要内部培养。产品经理负责产品规划，对短期业绩诉求和长期产品发展进行平衡管理，将业务创意转换成研发团队可以理解并实现的需求，并对研发交付的需求进行验收。产品经理和开发人员的配比应该在 1:6 到 1:10 之间，目前该角色在组织里多是配比不足的，这也成为了交付速度和质量的瓶颈。
-
测试分会长：测试资源的管理者，质量防线的设计师，负责守护部落交付质量。我们建议将测试人员分解，和开发人员一起混编成研发小队，而非将所有测试人员集中，形成测试人员资源池。测试分会长（部落内为分会，跨部落为行会）通过流程影响小队长和小队成员，在源头保证质量。TA还可以通过各种培训分享活动，提升整个部落的质量能力。**可以考虑在部落级别保持一支专项测试小队，负责测试框架、自动化、测试环境维护、性能测试等专项工作。**为了提升控制力，测试分会长应该是所有测试人员的汇报领导，对测试人员的考核具有最终决定权，这样既能提高该角色的影响力，也提供了一条快速通道，让研发小队里的测试人员能够自己升级质量风险。
-
架构师：系统架构的守护者，负责部落系统的长期质量守护，对系统发展和技术路线进行长期规划，明确各系统职责，并在各系统负责人的设计决定无法达成一致时进行仲裁。各系统的分管架构师负责该系统的整体质量，审核系统的核心设计，并对关键代码进行代码评审。
-
小队长、研发小队成员：研发小队由产品经理、开发人员、测试人员混编而成，一般不超过12人。产品经理负责澄清需求，并在业务负责人的授权范围之内，决策业务优先级。小队长负责组织小队成员交付需求，管理研发的容量、进度、质量。在SCRUM框架里，小队不设置负责人，由团队自组织运作，这超越了大多数组织的成熟度水平，在复杂架构的企业里尤其难以实现。
-
版本经理：部落交付的最后一棒，负责系统版本交付。版本经理负责规范化系统版本的制备过程，与运维团队对接，对系统版本部署到生产环境的全过程进行监控。
2. 有了组织，还要保证落地。这需要制定和贯彻流程管理规范。
-
具有仪式感的常规沟通：需求池月度会议沟通、线下会签定例展开；严控需求项目成本、执行收益报批；进行产品开发和进度跟踪，要求团队成员通过共享日历了解彼此的工作闲忙状态。诣在基于ADAPT形成自己的敏捷文化，打造适合自己的敏捷交付团队。
-
极其注重月度复盘：复盘的目标是从整体上了解团队的研发效能情况，及时发现研发过程的问题，通过问题分解和深入分析，找出问题的根因和改进点，从而驱动持续改进。久而久之也积累了一些复盘提倡的原则。
-
复盘还能助形成组织文化价值观。比如"过生日"文化、工作计划/进度/问题透明公开、提倡信守承诺、度量驱动持续改进、提升经营意识关注投入产出，以及鼓励内部积极分享、并形成"我做你看&你做我看"的会议主持风格。
-
在团队组织建设层面，提倡合适的人做合适的事。活用自有人力和驻场人力完成项目交付，比如自有人力熟悉业务、技能水平高，安排维护核心系统；其他短平快的产品迭代交与外包人员；对于供应商合作研发模式，以项目全包或者半包的方式灵活应对。
3. 敏捷迭代需要统一的流程
在流程层面，基于APAPT和SCRUM框架完善IT团队实现敏捷交付，并制定和遵循一套完整的从backlog-迭代-发版-运营的流程。
三、工具赋能实践
1. 插上工具的翅膀
我们基于腾讯云CODING DevOps平台改善数据分散原状，通过使用项目集、项目协同、代码仓库、代码扫描、持续集成、测试管理、制品仓库、持续部署、应用管理等功能，迅速实现了完整的敏捷交付工作流。并将CODING和内部运维平台、CMDB、以及接口压测平台系统集成，把所有的研发协作沉淀在平台上，进而将工程数据上报，拥有了自己的研发数据驾驶舱。
-
研发分支采用 Aone Flow 分支模型作为分支规范，并在CODING DevOps配置落地
在选择研发分支模型时，诸如Gitflow分支模型、GitLab分支模型等各有其优点和适用场景。我们的选择应基于自身业务的敏捷性以及电商零售行业面向小b和小C客户的具体需求。考虑到需要快速响应市场变化和客户需求，我们倾向于采用一种能够支持灵活、快速发布的模型 ------ 类似"快慢车发布分支"的策略。这种方式允许我们为每个业务需求创建独立的特性分支，这些分支以其对应的需求ID作为命名，确保需求与代码分支之间的清晰关联。
在开发过程中，每次提交（commit）必须包含相应的需求编号，这有助于追踪和管理代码变更，确保每个改动都能准确地与特定需求相关联。当某个特性分支完成开发并通过测试，准备发布时，开发团队可以根据版本计划和发布对象，将该需求分支合并到相应的发布分支进行集成和上线。这种模型的优势在于其灵活性。如果在集成过程中由于业务原因需要取消发布，我们可以轻松地重新选择和整合其他需求分支。这样的流程设计旨在最大化我们的敏捷性和应对变化的能力。
基于以上考虑，我们选择了基于AoneFlow的改进规范。这一规范借鉴了Gitflow等现有模型的优点，同时针对我们的电商零售行业To小b/小C场景进行了定制化调整，以更好地满足我们的业务需求和发布节奏。通过实施这一规范，我们期望能够提升开发效率，保证代码质量，并实现更顺畅的发布流程。
|------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 分支类型 | 命名规则 |
| 主干分支 | master |
| 发布分支 | release/devV20220105、release/testV20220106、release/stgV20220106、release/prd |
| 特性分支 | feature/CodingProjectId#CodingIssueId， 如feature/ecp#152411，152411对应为需求ID； ##如是该需求延伸出来的缺陷，在迭代未上线前，还是继续在原特性分feature/ecp#152411中修复。 ##如该需求有一个服务需多个人同时用不同分支开发的，可以以该需求创建的子工作项的coding id为起名分支名，并合并至feature/ecp#152411 |
| 非需求产生的缺陷分支 | bugfix/CodingProjectId#CodingIssueId， 如bugfix/ecp#195167，195167对应为缺陷ID； ##非需求产生的缺陷指的是生产缺陷、回归测试所发现的缺陷，不包括当前迭代缺陷 |
这些分支规范配置在CODING代码规范中，统一管理规范并将执行进行固化。目前配置规范包括：
a. F&S flow 分支规范：适用于多分支迭代并行的中大型开发团队使用快慢车发布，支持 master、feature/*、 release/*、bugfix/* 分支；
b. 允许创建规定分支类型以外的分支（CODING分支规范配置）；合并方向：规范仓库分支间的合并方向，只允许创建列表中规定方向的合并请求，列表为空则不会对仓库中的合并请求方向做限制；
c. CD flow 分支规范：适用于开发与测试中心一般规模开发团队，支持 master、feature/、 release/、bugfix/* 分支；
d. 允许创建规定分支类型以外的分支（CODING分支规范配置）；合并方向：规范仓库分支间的合并方向，只允许创建列表中规定方向的合并请求，列表为空则不会对仓库中的合并请求方向做限制。
注意！不存在一个分支模型适合所有场景的情况 ，选择研发分支模型时大家一定要根据不同模型的特点和团队规模、操作成熟度和业务特性来选择合适的分支模型。
-
在CICD环节通过CODING CICD以及腾讯云基础设施，实现全流程串联
容器化之前我们使用了 CODING 持续部署的主机发布，后来由于公司基础运维大部分都已经上云，云原生应用平台必须以应用为中心展开部署，不仅可以直接通过基础设施管理集群负载和应用的状态和信息，还能接入云上的链路追踪、监控、告警、事件、日志组件。因此后来改为采用 CODING 持续部署和 CODING Orbit Gitops 应用管理发布云原生应用，同时在CODING上采用 CODING 持续集成实现代码编译构建，结合本地MAC自定义构建机实现IOS发布。
制品管理方面，研发测试的制品采用 CODING 制品库，生产制品会采用腾讯云 TCR，以方便跨集群跨区域制品加速下载。
-
**开发与运维共享模板。**为了加强 dev 和 ops 的协作，我们制作了一些通用共享模板以统一规范管理和实现自动化：
***a.***构建模版一般由后端服务构建，前端app、uniapp、小程序打包模版快速复制，同时根据代码的更新自动触发、定时触发，以及模版中指定代码扫描门禁、自动化测试插件的方式构建统一的模版；
***b.***部署模版通过 CODING 应用管理设置，每一次的发布都会代码的commit记录，采用gitops方式管理每一次部署。我们维护应用的服务模版，定义服务的启动方式、端口、通用的apm和监控的agent、配置相应的健康检查（启动、就绪、存活、优雅关闭等），确保开发和运维使用相同的模版，并且每个部署的流程和部署环境可以选择部分的自定义替换，统一了运维监控的手段；
***c.***考虑到制品传输的效率，我们使用了统一的基础镜像源，从而提升了CI/CD效率，也保障了制品安全。
-
打通价值流 ，践行BizDevOps与数据驱动
a. 拉通项目集-项目空间-需求-子工作项-工时统计，实施管理跨项目业务需求管理；*b.*项目集工作项与内部系统打通建立立项项目审批流，一方面拉通了IT与业务相关组织，另一方面实现了业务目标（gmv/nps/DAU/收入等）与研发投入的关联，实现了从立项、财务结算、业务成本及ROI全流程管理；
*c.*建立效能看板，整合和清洗Coding系统、CMDB系统、内部考勤系统数据进行展示；
*d.*除了敏捷指标外，也添加了业务满意度、收入效益、流动速率等评价指标，从"快不快"、"好不好"、"省不省"等几个方面收集评价。
- 质量内建
在质量内建的层面，我们已经在需求、用例规范、单元测试和接口压测等方面做出了努力，以确保P0和P1级别的接口通过率，并且要求每次测试的通过率至少达到90%。然而，我们意识到可能仍存在未被发现的测试场景。因此，我们推出了质量内建2.0版本，其中产品和开发团队也承担了一部分质量保障工作，不再完全依赖测试人员。
***a.***在新的版本中，我们在需求评审、技术评审和用例评审过程中增加了会前评论数的参考，以避免评审流于形式且效果不佳。这一改变取得了良好的效果。通过这种方式，我们在需求的完整度、设计的全面性和测试的颗粒度上发现了许多问题，并能够尽早地暴露和解决。
***b.***为了提升代码质量，我们实施了质量左移策略，包括代码扫描、代码评审、接口开发自测和自助压测。我们提高了代码评审率和代码质量评分指标，并制定了开发接口自测的标准。我们还通过APIFOX对接口模型的设计、评审、mock、自测和自动化测试进行了集成。此外，我们实现了基于CICD效率提高的开发自助压测，压测环境能够在压测前自动扩容，结束后自动缩容。对于数据库，我们启用了云上的自动扩容功能，当CPU使用率达到50%以上时自动增加一倍的CPU和IO资源，当低于30%时自动缩容，这极大地提升了我们在接口功能和性能方面的质量左移。
***c.***我们还引入了基于jacoco的测试覆盖率工具，并将代码覆盖率不低于80%作为测试通过的指标。在提测阶段，我们会收集该功能分支的代码差异，并通过CICD模板在应用中进行插桩操作。如果代码覆盖率未达到标准，测试人员需要与开发人员确认未覆盖的代码分支和路径，进行测试场景的确认和补充，以提高测试的完整性。
***d.***除了上述措施，我们还根据需要进行兼容性测试和安全性测试。例如，我们可能会每季度或定期通过众测等方式进行这些测试，少量的兼容性测试则直接在腾讯Wetest 平台上进行调试。
借助工具优化了流程、规范了过程、提升了效率和质量，也实现了基于数据的持续改进。结合架构优化、变更管控和运维保障手段，构建了可靠稳定的业务支撑基石。
四、收益与总结
经过内部的数字化转型和DevOps效能提升的实际应用，IT团队已经取得了符合预期的收益：
-
研发交付现以业务需求为中心，旨在为公司创造价值。IT团队的角色已经从成本中心转变为直接推动业务收益的部门。
-
我们成功打破了部门间的壁垒，实现了协同工作和透明的工作负载分配。IT团队的角色转变为主动寻求业务需求，实施了从需求端到端的流程优化，提高了人员效率，并在此过程中重塑了组织结构。
-
我们解决了迭代范围不清晰的问题，将过去的迭代周期从3周甚至更长的时间优化为固定双周迭代版本交付。这一改变实现了有计划的交付节奏，使我们更有信心承诺满足业务需求。
-
我们已经摆脱了过去忐忑上线、熬夜发布的状态，转变为无需熬夜发布并尝试采用灰度发布的方式。这种转变不仅提升了发布效率，也降低了潜在风险。
最后，我们也期待未来能够借助开发工具的AIGC能力进一步加持无限极的研发效能提升。
