如何构建高效可信的持续交付能力，华为云有绝活！

摘要：持续交付的最终目的是高效和可信二者的结合。

1、高效可信的持续交付

1.1 软件研发的目的

持续交付是一个你们平时提得比较多的话题，高效是持续交付的目的，具体到华为云的场景下，持续交付的最终目的是高效和可信二者的结合。

整体而言，软件研发的目的是持续而且快速地交付高质量的有价值的软件给客户。首先研发是一个快速且持续交付的过程；其次研发是面向客户的，交付的软件必须是对客户而言高质量且有价值的，而质量是多方位多维度的，其衡量标准除了价值之外，还包括稳定性、安全性、可靠性、可扩展性等。

1.2 软件生命周期

从软件生命周期管理的全过程来看，产品的idea产生后，进入开发，而后到部署发布，最后到运维，这是一个端到端的完整的流程，每一个环节缺一不可。

• 开发环节，会有针对性地作各类测试，包括静态测试、动态测试、黑盒测试、白盒测试、灰盒测试等，这些测试会在不一样的环境之上分层进行，由不一样的角色去承载；
• 发布环节包括对在制品的管理，发布什么是由前端的发布计划决定的；
• 每一个环节都有部署的动做，自动化部署的过程会衔接前端的开发过程。

往深一层：

• 整个前端更多的是创新的过程，在这个过程当中能够看到不少方法论，好比设计思惟、精益创业、数字化转型等，这里的创新表明的是业务侧的诉求，传统业务须要经过新的方法、新的技术来实现赋能和转型；
• 创新的idea落到研发环节去实现，开发部署发布有CI/CD进行支撑；
• 最后到运维和运营，不仅是上线后须要运营，像如今服务类的产品都讲究云化，既然是一个service，就须要对service构建整套面向用户、面向内容、面向产品的运营体系。

回到业务侧，将上述从产品到研发的流程映射到整个产品生命周期。

• 偏前端的阶段是增值类的，产品创新是有价值的，写的代码也是有价值的；
• 而偏后端的阶段则是非增值的，好比测试，对最终客户来讲是必要但不增值的。

增值的部分，咱们追求的是最终的效果；非增值的部分，咱们追求的是效率，即我要高效地完成这个过程，以便于达到最后的结果。

要经过过程来保证效果，所以过程也是必不可少的。但在这些过程当中有不少工做是重复的，好比测试、部署，咱们须要经过自动化的方式去赋能。这就是咱们一般讲的DevOps的意义，经过自动化的流程和工具，让机器去完成重复性的工做。

观全貌咱们不难发现，在整个软件/产品生命周期，质量经过逐层的测试、验证、反馈等贯穿始终。另外，其中也包括大量安全类的活动，好比在产品创新阶段要考虑安全性的诉求；在开发过程经过黑盒、白盒、静态、动态等测试保证安全。

最后落到可信的层面，华为整个研发体系服务于总体的业务诉求，你们都知道，华为处于通讯行业，通讯是一个关乎国计民生的领域，对安全的要求很是高，提供的产品和服务必须可靠可信，所以咱们作了不少可信工程的设计。

2、可信工程

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、开发与集成

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、测试与反馈

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、安全与审计

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、部署与发布

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测试进行业务层面的探索，咱们一直强调经过技术的手段赋能业务。

7、总结

以上介绍的是华为云的DevOps体系，其核心除了一般咱们所说的“高效”、“持续交付”之外，更重要的一点是“可信”。咱们将这一体系称为“云与安生时代的DevOps体系框架”。

顶层是商业决策，咱们会持续规划、按期审视，固定节奏对其进行相应调整；往下是服务化组织、架构解耦，开发&运维落地；再往下是工具、环境支撑；最底下是服务流程支撑。

如何去构建这样一套体系？咱们要始终围绕总体的研发效率目标，选择应用相关的研发工具，以工具承载新型能力，支撑高效做业、持续交付、高效协同、智能化辅助开发、持续反馈与改进，进而构建整个的持续交付能力。

——————————————————————————————————————

内容来源：【2020 CSDI SUMMIT中国软件研发管理行业技术峰会】分享实录，原文首发于“百林哲”。做者：姚冬

嘉宾简介：华为云应用平台部首席技术解决方案架构师，资深DevOps与精益/敏捷专家，华为云享专家，中国DevOps社区核心组织者，IDCF（国际DevOps教练联合会）发起人

 

点击关注，第一时间了解华为云新鲜技术~