摘要：持续交付的最终目的是高效和可信两者的结合。
一、高效可信的持续交付
1.1 软件研发的目的
持续交付是一个大家平时提得比较多的话题，高效是持续交付的目的，具体到华为云的场景下，持续交付的最终目的是高效和可信两者的结合。
总体而言，软件研发的目的是持续并且快速地交付高质量的有价值的软件给客户。首先研发是一个快速且持续交付的过程；其次研发是面向客户的，交付的软件必须是对客户而言高质量且有价值的，而质量是多方位多维度的，其衡量标准除了价值以外，还包括稳定性、安全性、可靠性、可扩展性等。
1.2 软件生命周期
从软件生命周期管理的全过程来看，产品的idea产生后，进入开发，然后到部署发布，最后到运维，这是一个端到端的完整的流程，每个环节缺一不可。
- 开发环节，会有针对性地做各种测试，包括静态测试、动态测试、黑盒测试、白盒测试、灰盒测试等，这些测试会在不同的环境之上分层进行，由不同的角色去承载；
- 发布环节包括对在制品的管理，发布什么是由前端的发布计划决定的；
- 每个环节都有部署的动作，自动化部署的过程会衔接前端的开发过程。
往深一层：
- 整个前端更多的是创新的过程，在这个过程中可以看到很多方法论，比如设计思维、精益创业、数字化转型等，这里的创新代表的是业务侧的诉求，传统业务需要通过新的方法、新的技术来实现赋能和转型；
- 创新的idea落到研发环节去实现，开发部署发布有CI/CD进行支撑；
- 最后到运维和运营，不只是上线后需要运营，像现在服务类的产品都讲究云化，既然是一个service，就需要对service构建整套面向用户、面向内容、面向产品的运营体系。
回到业务侧，将上述从产品到研发的流程映射到整个产品生命周期。
- 偏前端的阶段是增值类的，产品创新是有价值的，写的代码也是有价值的；
- 而偏后端的阶段则是非增值的，比如测试，对最终客户来说是必要但不增值的。
增值的部分，我们追求的是最终的效果；非增值的部分，我们追求的是效率，即我要高效地完成这个过程，以便于达到最后的结果。
要通过过程来保证效果，因此过程也是必不可少的。但在这些过程中有很多工作是重复的，比如测试、部署，我们需要通过自动化的方式去赋能。这就是我们通常讲的DevOps的意义，通过自动化的流程和工具，让机器去完成重复性的工作。
观全貌我们不难发现，在整个软件/产品生命周期，质量通过逐层的测试、验证、反馈等贯穿始终。另外，其中也包括大量安全类的活动，比如在产品创新阶段要考虑安全性的诉求；在开发过程通过黑盒、白盒、静态、动态等测试保证安全。
最后落到可信的层面，华为整个研发体系服务于整体的业务诉求，大家都知道，华为处于通信行业，通信是一个关乎国计民生的领域，对安全的要求非常高，提供的产品和服务必须可靠可信，因此我们做了很多可信工程的设计。
二、可信工程
2.1 华为软件工程建设历程
自上世纪四五十年代起，开始有了第一台大型计算机，软件工程也随之兴起并发展至今。华为成立于1987年，最开始是单兵作业或小团队作业的方式，后来随着业务的增长团队规模不断扩大，如何支撑大规模集团军作业？为解决这一问题，我们开始引入IPD，由此进入IPD1.0时代。随着互联网技术的发展，有了敏捷开发、CMMI、DevOps持续交付、云原生等方法论和实践，我们将这些优秀的方法论和实践合并到IPD1.0的框架中，使之更灵活地适应实际的软件研发需求。
2019年起，我们开始做IPD2.0，其中一个非常关键的点是可信。
2.2 何为“可信”
我们先来给“可信”下个定义。
可信是每个系统在业务意图之外同时具有韧性、Security安全性、隐私性、Safety安全性、可靠性、可用性六个特征的确定性程度。
也就是说，每个系统在业务意图（即功能性诉求）之外，还需要同时具备6个特性：
- 韧性，服务宕机是否能够自动拉起来？系统能否经受得住大规模并发冲击？
- 安全性，这里有两个单词代表安全性特质：Security和Safety。其中Security侧重数据安全、信息安全，Safety侧重环境安全等。
- 除此以外，还需要考虑隐私性、可靠性、可用性等特质。
华为的可信工程将这6个特性作为基本的诉求，再关联业务意图，高效地完成业务目标，带给客户价值的同时兼顾可信。
2.3 可信价值流框架
如果大家了解精益等实践，就知道研发实际上是一个价值流交付的过程。那么，可信价值流框架是什么样的呢？可信价值流框架是产品生命周期端到端的过程，以终为始，我们要的是结果安全、结果可信、过程可信，即我们通过过程的可信达到结果可信赖、可依赖、安全的目标。
将整个产品生命周期进行拆解：
- 在安全治理层面，我们需要有可信治理，包括可信要求、责任和权利、分层级治理、人才和文化等；
- 在过程可信层面，要有相关的确定性预防、确定性应对、机密性、完整性、一致性和双向可跟踪性、风险管理等，在过程中做到整体把控；
- 最后到结果可信层面，包括前文提到的6个特性。
再细化下来，又涉及到产品定义阶段、产品实现阶段、产品预发布阶段、产品使用阶段等，每个阶段都在传统软件工程的基础之上，加入具体的动作去满足整体可信的要求。比如，产品定义阶段，在规划和设计中考虑可信诉求；产品实现阶段，考虑编码是否安全、编译是否多次可用，交付给不同客户的软件包是否正确，测试是否可重复……在产品预发布和使用阶段也会有很多相应的策略实现可信。
技术层面，我们通过使用建模和仿真技术、密码学的加解密协议、操作系统可信等技术使能可信。
这是一条完整的通过过程可信达到结果可信的路径，最终我们通过各级度量进行持续改进。
2.4 华为云HE2E DevOps框架v2.0
华为云集合业界先进理念和华为30年研发经验，总结出一套可操作可落地的端到端一站式开发方法论和工具链——华为云HE2E DevOps框架。
- 首先，它是端到端的DevOps开发框架，包括从规划设计到迭代开发到持续测试再到持续交付的全过程。我们认为仅仅只做好工程端不足以支撑整个业务，一定要延伸并回归到业务侧，实现端到端的闭环。
- 其次，它的整个过程融合了大量以可信为目的的手段，去支撑整个DevOps流程。
华为云HE2E DevOps自2018年发布1.0版本，到今年发展为2.0版本。华为云HE2E DevOps框架v2.0整体分为6大阶段：规划与设计、开发与集成、测试与反馈、安全与审计、部署与发布、运维与监控。本文将着重介绍工程端的内容，包括开发与集成、测试与反馈、安全与审计、部署与发布。
三、开发与集成
3.1 CloudNative实践
云的服务本身就是生于云长于云的，因此我们一直在做CloudNative实践，在架构、工程交付、全功能团队、云环境四部分不断优化，持续提升质量。
- 架构优化，架构整体进行微服务改造，统一微服务框架到SpringCloud里，进行业务拆分架构解耦，轻量级通信。
- 全功能团队，架构拆分后，团队需要根据架构做相应的验收和匹配。我们试点服务化全功能团队，单个Service由2-Pizza小团队对开发、测试、部署上线、运维端到端负责。
- 工程交付，践行DevOps交付模式，构建端到端交付流水线，微服务独立开发、构建、测试、部署、发布、现网运维。
- 研发全云化，依赖研发云I层和P层资源和成熟基础服务，基于华为云打造云化服务工具链和环境。
3.2 Cloud Native能力构建铁三角
从以上4个方面我们不难得出构建云原生的Cloud Native能力必不可少的铁三角：架构、组织、工程，我认为中间还应该加上价值交付。回到最初那句话：研发的目的是持续并且快速的交付高质量的有价值的软件给客户。
1）架构层面
- 采用服务化架构/微服务架构实现全面解耦。把系统划分为多个功能内聚、粒度合适、业务边界清晰、独立自治的服务/微服务。
- 使用自服务、敏捷的云化基础设施服务。依赖底层云化基础设施的服务提供运行资源，使用云监控服务监控自身运行状态，同时根据运行状态出发运维事件，实现弹性伸缩、故障自愈等。
- 通过API重用云原生公共服务提供的基础能力和架构能力。不管内部还是外部的服务之间，都可以通过API的方式自动生成相关接口和用例，来进行构建和定义，包括数字化转型里的开放平台、开放银行等都是通过API来进行支撑。现在比较流行的说法“API经济”可以了解一下，此处不展开。
2）工程层面
- 系统与环境、流程、配置解耦，人员团队之间也进行相应的解耦与匹配。
- DevOps，运维和开发相互融合，高度协同，共担职责。
- 实践极速迭代，持续交付，快速相应业务变化，缩短TTM。
3）组织层面
- 全功能团队，团队中包括产品、架构、设计、开发、测试、运维等角色，吃自己的狗粮，自己的产品一定要自己去上线发布和维护，每个人轮岗去负责发布的过程，这样所有人都知道产品上线发布的流程。这样做有几个好处：技能的相互传递、打造全栈，不会依赖于某一个角色。
- 云化运维团队，基于云平台提供的监控、报警等能力，成立专门的团队负责系统运行时的质量，保证系统可用性和业务无中断的升级、回滚。运维团队更多的是构建工具平台和流程，进行赋能。
3.3微服务化目标
- 系统解耦，功能内聚，提升需求交付效率。通过业务的拆解和解耦，让系统敏捷起来。
- 践行API First。通过服务化，让服务提供者和消费者之间通过微服务API建立契约。
- 低成本可伸缩架构。可灵活进行水平、横向扩展，平滑上云，架构上支撑应用市场业务的快速发展。
- 服务自治。通过在线的微服务治理结合云平台，实现微服务的弹性伸缩、熔断降级等。
- 探索一体化服务团队。建立2-Pizza Team，通过全功能团队的建设，让业务真正敏捷起来。
3.4微服务实践 - 顶层统一设计
总结起来是：大兵团作战，顶层设计，统一认识，组织赋能。角色上分为研发&运维团队、设计&开发&测试骨干、架构师，每个角色要做什么，通过培训和赋能的方式来进行定义和支撑。
3.5 微服务12设计原则
我们有一套一站式的微服务管理平台来支撑微服务的12设计原则。
3.6 Clean Code
1）Clean Code机制
业界一致认为，编写Clean Code能有效减少漏洞，降低系统脆弱性，是实现软件可信的重要举措。我们内部也非常强调Clean Code（代码整洁），建立起一整套完整、具备快速反馈能力、可持续生成好代码的机制。
华为有自己的Clean Code定义和文化。通过Committer机制、门禁机制、代码极致共享等做相关过程的支撑，通过开发者测试对整体质量进行把控；并建立三层模型和六级标准，支撑实时代码评估、版本交付阶段性评估和产品长期演进的年度评估。
2）Clean Code评估
业界Clean Code评估标准是：高效、可移植、安全、简介、可靠、可测试。华为持续对业界最新标准进行有效的代码评估，并结合实践建立了三层质量模型和六级质量评分标准。
关键举措包括：建设分级标准，我们会对不同系统进行评级；开发可视化工具；建立定期评估指导场景；持续对标业界刷新评估模型。
3.7 华为Committer工程实践
Committer来源于开源社区，大家都知道开源社区的协作模式是分布在全球各地的开发者以协同贡献的方式进行开发，代码贡献者的能力、水平、责任心等参差不齐，因此必须在代码入库之前进行Committer评审以保证质量。华为内部也有开源的机制，借鉴这一实践，形成自己的Committer机制。
华为的Committer机制实际上是一套流程来保证整体的代码质量，包括三个角色：
- Developer，负责创建本地代码分支、本地开发、开发自检与测试等工作；
- Reviewer，负责对代码进行检视；
- Committer，负责做最后的质量把关。
底层通过IT基础设施来保证编译部署、测试等过程，通过自动化工具使能，减轻评审的重复劳动。
整个Committer流程由几个核心点：
- 代码的开发、提交与合入权限应要分离，以避免攻击者冒用员工权限植入恶意代码；
- 通过检视和审核的意见对工程师进行辅导提升团队软件能力。
- 入库审核还能反向驱动前端代码检视提升，促进Developer具备编写Clean Code的能力。
四、测试与反馈
4.1 华为云全场景测试服务框架
华为云全场景测试服务框架提供一站式端到端测试自动化智能化解决方案，为企业构建测试中台，提升企业测试专业度及测试效能。整个测试框架分为三大块：测试设计、设计执行、测试分析，包括测试设计、测试用例管理、服务接口测试、WebUI测试、终端测试、性能测试、安全测试、导流测试、在线测试及测试分析报告等功能。底层有一套完整的测试管理平台来支撑。
全场景测试服务有3个要点：
- Test Left，测试左移。在研发或产品生命周期的早期阶段就可以介入和开展测试，并且测试的工作不是只由测试人员来承担，也就是说测试是一个活动，而不是一个独立的角色。
- Automate Everything：尽可能多自动化。在业务早期阶段，快速构建起来做一些验证，所有这些测试用例逐渐都要变成自动化的方式，这样才能重复性地、一遍一遍地支撑业务快速交付的过程。
- Test Right，测试右移。类生产环境始终不是真正的生产环境，没办法模拟所有生产环境的场景，我们还需要开展大量的线上测试。
全流程测试，每个阶段都有对应的测试动作：开发环节有验收测试、单元测试、功能测试、coding里的代码质量把控也是测试；测试环节有回归测试、集成测试、性能测试、安全合规类测试等；部署环节有A/B测试、在线上环境和生产环境做一些复杂测试，还包括吃自己的狗粮等。
整个测试会分三级进行，分别是个人级、服务级、产品级。每级的流水线都会涉及到质量活动，流水线也会分层分级：
- 个人级流水线的质量活动是从本地开发环境到Alpha环境，包括代码检查单元测试、编译构建、安全扫描、接口测试等，然后通过分支合并到Beta环境；
- 服务级流水线的质量活动是从Beta环境到Gamma环境，除了上述测试以外，还需要跑老特性回归测试、浏览器兼容性测试、性能测试等；
- 产品级流水线的质量活动是从Gamma环境到生产环境，本层级需要加入专项测试，比如产品级性能测试、可靠性测试、长稳测试、安全测试等。
4.2 微服务交付过程持续开展质量活动
在微服务交付过程中有不同的环境，比如Alpha环境、Beta环境、Gamma环境等，每个环节有相关的质量检查门禁和验收标准，以及现网的质量活动。这些质量活动由不同的角色来承担：
- 前端设计阶段，参与的主要是架构师和开发工程师；
- 开发过程主要由开发工程师来承担，架构师也会承担开发的工作，但他做得更多的是关键的跨服务之间的设计和开发；
- 发布阶段，开发工程师执行发布的动作，测试工程师会从端到端进行质量把控，并对开发工程师进行支撑和赋能。
- 生产环境，开发工程师和运维工程师一起对系统进行支撑，测试工程师会做一些现网测试、导流测试、混沌测试等。
4.3 测试度量指标体系
除了流程以外，我们还会有一些质量定义和度量标准。测试度量标准总体分为两类：过程指标和结果指标。过程度量包括：覆盖率、执行率、测试效率等；结果度量包括：功能测试、性能测试、安全测试、可靠性测试等。
五、安全与审计
5.1 DevSecOps的价值和实践
安全和可信直接相关，说到可信，大家自然会联想到安全。权衡DevOps速度与现有安全要求的需求，催生了一个名为DevSecOps的模型。
什么是DevSecOps？DevSecOps基于“安全问题，人人有责”的原则，它强调应用程序开发人员可以怎样把安全检查与他们的集成和部署流水线构建到一起。简单来说，就是把安全层面的活动渗入到DevOps开发过程的各个环节中。 在华为云的实践中，我们更关注在软件开发过程中植入安全活动保证软件生产的可信可靠和稳定。
5.2 华为企业级安全工程实践
同样从软件生命周期来看，华为企业级安全工程实践基于DevOps流水线，在计划、编码与构建、验证、发布与运维运营等每个阶段都有相应的安全考核点和实践介入，底层会有标准和规范、技术和能力、工具和流程来支撑，全流程保障网络安全，实现安全设计、安全编码、安全测试、安全运维。
5.3 CodeCheck安全
华为内部自研了一个工具：CodeCheck，以应对严苛的安全要求，保证整体代码质量和安全。我们分别从能力、效率和生态运营来看CodeCheck。
- 能力上对应三个级别：桌面级-编码开发环节，嵌入IDE，编码时执行快速检查；个人门禁级-代码提交入库时，提供入库门禁和规则集，快速检查；版本级-持续集成、持续交付的过程中，提供全量检查、告警闭环处理工程化能力。
- 效率上，前端桌面级和个人门禁级可做到秒级至分钟级标准；到了线上环节，因为要跑的环节非常多，所以是小时级。
- 生态运营上，我们的工具是对内做服务，对外做客户支撑。
5.4 安全规则
我们的安全规则来源于两个层面：
- 外部视角：借鉴外部的规则，将业界的标准和最佳实践沉淀下来，变成安全编码的知识库和规则集。
- 内部视角：华为内部有大量的产品线和产品形态，我们定义出TOP10的质量和安全问题，将长期场景梳理和安全检查的经验积累成规则。
业界经常提及的静态分析安全测试（SAST）包括四层：编译、构建、语法分析、语义分析，安全检查涉及的技术栈明显更深，华为提供全栈能力、多语言支持，支持深入的语义分析能力。如果把质量和安全结合到一起，需要一些规则和引擎来支撑，还需要引入一些智能化的手段，自动检查、自动修复。
华为内部将规则集分为三层：公司级、产品线级、产品级/版本级/工程级。公司级规则集包括强制规则集，比如低误报，默认必须扫除，而检视规则集则可根据需要勾选；产品线级规则集和产品级规则集，产品线管理员配置为强制要求，其余的规则集可根据产品特性进行选择。
整个工具不仅仅是简单的安装+运行，而是一个MN矩阵式的运营体系。从规则定义上来讲，有公司级、产品线级、产品级等不同层级的规则；从时间周期上看，哪些规则放在开发者桌面IDE里、哪些规则要放在流水线里、哪些规则要放在版本构建里，都有一个设计的过程。
5.5 企业级专家服务
在安全层面，我们提供了企业级专家服务，其服务策略类似于医院看诊。普通“发烧感冒”的诊治，提供基础服务；针对“大病重症”，提供专业的自动化检查能力及工程配套能力；针对“疑难杂症”，提供顾问式专家服务。
六、部署与发布
6.1 持续交付核心实践
持续交付的过程是和持续开发与集成、自动化测试等关联在一起的。比如分层快速闭环，在测试的时候就会分不同的层级去执行，分层的目的是为了快速反馈和闭环。
持续交付的核心实践除分层快速闭环外，还包括：小迭代高节奏交付、自动化&可视化流水线、自动化持续部署、缩短单点耗时、高效标准化环境等。
6.2 发布的分支模型和CI/CD流水线
自动化部署的背后是标准化环境，需要代码的分支结构和整体的CI/CD流水线有很好的匹配和映射关系。
我们从代码主干上拉出来一个代码分支，在上面做相关的开发，提交后自动拉起来一个CI流水线，对代码进行静态检查和自动化构建，包括部署包准备、代码合并等，最终通过个人级别的流水线后，跑到生产环境上，整个过程都是和CI/CD流水线关联在一起的。
6.3 可信Built-In的流水线
我们把可信的概念内建到整个流水线里，自动化检查、验证，过程中获取反馈，支持实现CI/CD过程的高效可信。
如果代码层面是可信的，到编译构建的时候，可以可重复地高效地构建出来；同时，测试活动中也会加入可信相关的检查点；到上线后，Chaos Monkey等实践也都是跟可信直接相关的，比如我们经常强调的弹性、稳定性等。
6.4 Everything as Code 一切皆代码
可能有人会问：怎么防范我的环境里被人植入漏洞？其实环境也好、过程也好，都可以代码化，代码化后就可以把它纳入到整个版本管控中，这样的话所有的修改和变更都可以自动化，也可以针对这些环境和过程进行安全审计。
我们称之为Everything as Code 一切皆代码。除了基础设施以外，编排、配置、测试、数据库、流水线、代码都可以这种方式呈现出来，这样就可以实现版本化、自动化和标准化。再往上到Service也如此，Service as Code实际上就是我们想要强调的API。
6.5 灰度发布策略驱动自动化部署与回滚
在发布的时候，我们会有各级发布的机制。首先我们会做一级的灰度发布，找一些重点MVP客户，或者内部使用者，发布给自用环境；没问题的话再进行二级灰度，这时会适度扩大范围，开放给全网10%左右的用户；然后再做三级灰度；最后才是全量发布。
在这个过程中，一旦任何一级出现问题，马上就可以进行修复和回滚。同时我们会做一些在线导流测试，结合AB测试进行业务层面的探索，我们一直强调通过技术的手段赋能业务。
七、总结
以上介绍的是华为云的DevOps体系，其核心除了通常我们所说的“高效”、“持续交付”以外，更重要的一点是“可信”。我们将这一体系称为“云与安生时代的DevOps体系框架”。
顶层是商业决策，我们会持续规划、定期审视，固定节奏对其进行相应调整；往下是服务化组织、架构解耦，开发&运维落地；再往下是工具、环境支撑；最底下是服务流程支撑。
如何去构建这样一套体系？我们要始终围绕整体的研发效率目标，选择应用相关的研发工具，以工具承载新型能力，支撑高效作业、持续交付、高效协同、智能化辅助开发、持续反馈与改进，进而构建整个的持续交付能力。
——————————————————————————————————————
内容来源：【2020 CSDI SUMMIT中国软件研发管理行业技术峰会】分享实录，原文首发于“百林哲”。作者：姚冬
嘉宾简介：华为云应用平台部首席技术解决方案架构师，资深DevOps与精益/敏捷专家，华为云享专家，中国DevOps社区核心组织者，IDCF（国际DevOps教练联合会）发起人
转载：https://blog.csdn.net/devcloud/article/details/112802813