下一代端到端的软件交付

李威——JFrog 解决方案架构师。DevOps咨询师、教练，曾就职于烽火、京东等企业，十余年一线开发及运维经验，带领团队从零到一实践DevOps转型。现就职于JFrog，善于在工程实践方面引导帮助客户落地DevOps。

▼

随着第四次工业革命的进行，下一代持续交付体系与10年前已经有了天翻地覆的变化。软件自动化大大缩短了发布周期，软件分布式运行在私有云、公有云等不同环境，物联网连接着数百亿台设备，无时无刻都在进行软件的更新，使持续交付的可靠性受到了前所未有的挑战。在此期间，大部分企业都已经实践了DevOps，但对于组织间的协作，工具链建设、软件供应链风险、软件的可信质量、持续交付的速度等依然存在大量的问题。DevOps倡导所有新的功能特性可以像流动的水一样，迭代到用户的终端，在这个设想下，软件企业就是供水公司，为了保证水流的质量，必须在水流动的途中治理，直到最终交付到用户的手中。用户需要时可以随时打开水龙头，就可以获得达到质量标准的水（软件）。这也就是DevOps建设中一个新的理念“liquid software”。

开启话题之前，我们先来回顾一下10年前的持续交付是什么样子。大部分本文的读者应该都阅读过《持续交付-发布可靠软件的系统方法》（如果没有看过，请立即去看），这本书被认为是近十年持续交付的北斗星，内容包括配置管理、持续集成、部署流水线、构建自动化、测试与验收、部署与发布等软件生命周期的完整理论与实践。直到今天，我们根据谷歌2022年DevOps加速状态报告中调查结果发现，版本控制、持续集成、持续交付、松耦合架构等内容仍然是提高工程效能的最佳实践。所以本文并没有对近10年的持续交付实践有任何质疑成分，只是在面对未来的软件交付趋势的分析与探讨。

世界知名预测组织IDC的2019年预测报告指出，未来超过70%的企业会选择使用云服务，这一预测已经在2022年予以验证，通过2022年谷歌DevOps加速状态报告中指出，只有10%的企业没有使用云服务。使用云服务的组织绩效目标可能高出未时使用云的组织14%。IDC预测报告中还指出，2023年，将有超过50%的企业基础设施会部署到边缘，到2024年，被部署到边缘环境的应用总量将是2019年的8倍。现在，面对着物联网环境下，随着OTA技术的成熟，汽车、基站、电子设备中运行的软件都需要实时更新，这对于目前我们所具备的持续交付能力还无法应对这种端到端的交付场景。另一个现阶段我们需要考虑的就是软件供应链安全的问题，在2020年之前，很少有人会考虑到软件供应链风险的问题，知道SolarWinds，改变了这一切，而今天，软件供应链风险已成为阻碍大部分企业快速交付的瓶颈点。所以面对下一代软件交付的场景，软件安全、软件分发已经成为下一代端到端软件交付的主题，为了让我们更快的交付有价值的软件，必须在持续交付的过程中解决软件分发与软件安全的问题。

那么，下一代端到端的持续交付体系如何设计呢，笔者认为在下述几个方面提前布局，以便应对应用软件爆发式交付的场景。

— 1 —

持续交付的加速剂“元数据” 

元数据（Metadata）是用来描述数据的数据（data about data），主要是描述数据属性（property）的信息，用来支持如指示存储位置、历史数据、资源查找、文件记录等功能。

制品元数据顾名思义，就是用来描述软件制品位置、历史记录、属性的数据，同时我们可以通过软件制品元数据来快速过滤查找软件。

如今的软件发展中，每个软件的产生都需要经历完整的软件生命周期，从需求的诞生，到编写的代码、代码的质量检查、编译的过程、测试的结果、安全的验收、软件的发布与监控等。这些统一称之为软件的生命周期信息（SDLC，Software Development Life Cycle，软件生命周期，即软件的产生直到退市的生命周期，是软件工程中的一种思想原则，即按部就班、逐步推进，每个阶段都要有定义、工作、审查、形成文档以供交流或备查，以提高软件的质量）。为了将软件生命周期更好的收集和记录，我们用到了元数据的方式，将软件与生命周期属性做关联。

关联到每个制品都存在必要的元数据，确保软件安全可靠。

发团队构建制品版本，并将过程数据、需求数据、测试数据、匹配机型数据等自动补全在软件制品的元数据属性中，如未携带此数据，则无法成功上传。测试人员在使用软件制品进行烧机测试时，则通过自动化脚本，自动筛选符合自己机型并具备一定质量属性的制品，自动测试，整个版本筛选过程无需人与人的沟通，一切自动化完成，提高效率，避免出错。

软件“元数据”保障了软件的质量，提高软件的透明性，是打通开发与运维之间部门墙的一把钥匙。通过元数据，是我们软件交付更流畅，更可靠，更便捷。

— 2 —

供应链安全对持续交付的影响

软件吞噬世界、开源吞噬软件。大部分的软件包含80%-90%的开源组件。2021年全球发生的软件供应链攻击时间比前一年增长了650%。由于企业及用户对软件交付速度越来越高，导致安全治理难度成指数级增长，尤其在端到端的交付场景中，面向车企、医疗、金融、政府等行业交付软件时，软件安全的话题更容不得一丝马虎。2022年谷歌DevOps加速状态报告中指出“帮助企业将安全实践纳入现有的开发工具与流程中，而不是在发现威胁的时候进行额外的工作或演练，会显著的降低安全风险。安全实践会对组织绩效产生积极影响”。

由于大多数开源软件及组件是使用制品的方式被引入组织内部的，因此控制入口就成为管控的关键。如果没有统一的引入源头和平台，则使用者会随意下载开源组件及软件，并直接在组织内使用，其带来的风险无法清查，对开源的使用、更新、退出等流程也无法监管。当编译构建制品时，我们可能会引用成百上千个第三方的组件，如何在CI期间运行漏洞扫描，如何记录制品之间的引用关系就成为对风险组件管控的关键。我们需要在软件开发的全流程来把控软件供应链的安全，并尽量做到安全左移，越早发现安全问题，处理的成本就越低。我们需要把安全扫描动作提前到CI中，甚至需要提前到开发人员编码的过程中，提高安全意识，让开发人员主动处理安全风险问题，合规使用开源供应链，加速交付的前提下，保障软件安全。为此，我们需要在软件供应链引入层面、使用层面、影响性分析层面投入更大的力量。只有在软件开发的过程中去解决安全问题，才能降低软件安全对持续交付的负面影响。

— 3 —

“软件分发”对下一代交付场景的必要性

iot-analytics.com统计分析指出，截止2021年底，全球活跃的物联网终端设备（不包括手机）已经超过120亿台，预计在2025年前将以每年22%的速度增长。对于现代的物联网设备（5G基站、自动驾驶汽车、无人机、机器人等），实时在线、实时更新是最基本的需求。

软件持续交付并不是指在开发环境的持续交付，面对端到端的交付场景，软件最终需要交付到私有云、公有云、生产工厂、设备终端等不同国家的不同数据中心。主要需要面对下面两种场景：

• 跨网络环境的软件交付

部分企业需要考虑网络环境隔离的特殊性（如金融行业），这些企业往往会存在研发中心、测试中心、多地数据中心等，并且在网络层面并不能随意访问。传统意义上的持续交付，今需要在开发环境完成代码开发、编译构建、测试验证，但随着软件交付投产，势必需要运维人员手动的去操作跨网络的软件同步。面对这种场景、有人参与执行的位置必为安全及合规的薄弱点。我们需要将跨环境的软件交付自动化，通过软件层面的单向可信同步，让本来不透明的交付内容在开发团队与运维团队之间变得可信。这离不开持续交付工具及上文中我们所提到的软件的“元数据”。

• 多数据中心软件分发

制造业（手机、车企、医疗）需要考虑软件的全球分发与实时更新。此时，企业需要在软件交付层面考虑混合云架构。可通过私有云或公有云，实现软件版本实时同步，物联网设备、工厂、售后站等需要实时更新软件的位置可以就近获取到更新的软件版本，从而解决下载缓慢、丢包等问题。同样，这依赖于我们在软件开发过程中，对安全可以加以把控，并对元数据深度记录，满足此前提情况，就可以优化我们的CI流程，将自动构建的软件版本，实时并且按需的分发到世界的每一个角落。

更必要时，我们需要打造OTA（空中下载技术）平台，来实现终端设备的实时更新，面向上万台设备可以通过简单的API，将CI构建的软件直接发布到物联网设备上（如汽车、机器人、无人机等）。

最后，面对下一代端到端的交付场景，我们需要在现有的持续交付体系上，更多的考虑软件的完整生命周期的可控性，基于软件的元数据来对软件的质量与可靠性进行评估；通过在安全方面的提升，重用开源，降低开发成本的基础上，保障软件供应链的安全；并在复杂的网络交付场景下，设计一套可以快速交付到数亿台终端设备的软件持续交付方案。

我们分析某个软件系统或子系统的当前的软件交付过程，评判哪些方面做得好、哪些方面做得不好时，思考是不是应该做某项改进时，总得有一个判断标准。我们经常说，要有更高的效率，要有更好的质量。然而，质量真的是越高越好吗？质量和效率有矛盾时怎么办？更高的效率到底是什么意思呢？

28日晚八点，K+talk特邀前京东首席架构师叶赫华和DevOps专家/前阿里研发效能事业部架构师董越做客直播间，与大家共同探讨“怎样才算高效能的软件研发？”，赶快扫码预约观看吧！