极氪软件及电子中心 Filip

经过十多年的发展，敏捷软件开发已经从一种前卫的开发方式转变成为在各大软件公司中被广泛应用的主流技术，变成了互联网行业的一种潮流，而随着软件定义汽车等概念的兴起，软件在一辆汽车中的价值正在不断增加。电动化、网联化、智能化、共享化的背后都需要强大的软件能力作为支撑，而软件能力不仅体现在构建出高质量的软件产品上，同时还体现在软件产品的快速迭代以满足快速变化的市场需求的能力之上。这样的变化无疑给汽车软件开发带来了新的挑战，同时也带来了巨大的机遇，新玩家纷纷入场，期望在软件和用户体验上赢得市场，而传统的汽车制造商则正重新审视组织架构、人才、流程、职责等方方面面以期适应新的变化，成为软件驱动的公司。

持续集成/持续发布（Continuous Integration and Continuous Delivery）是敏捷软件开发中的核心过程，本文将从的持续集成/持续发布角度探讨汽车软件开发过程中的代码管理和发布流程。

传统汽车软件的开发流程

传统汽车软件开发大量依赖于供应商，汽车制造商提出需求，由供应商负责软件编写和实现。在过去十几年的时间里，汽车电子器件的数量增长迅速，车内电子控制单元（ECU）从十几个增长到了上百个，带来的是软件复杂度的快速增加。除了汽车功能繁多所带来的软件复杂度，汽车电子类产品在软硬上往往对设备的高可靠性、稳定性有着严格的要求，这些要求在消费电子类，甚至是医疗电子类和工业控制类产品上是没有的。因此，为了满足功能安全等要求，汽车的软硬件往往需要做额外设计。面对这样的复杂系统，汽车行业制定了许多标准及方法论以规范开发过程，而在软件开发过程中，最有名的是 ASPICE（Automotive Software Process Improvement and Capability dEtermination）。

Automotive SPICE 简称 ASPICE，是 ISO/IEC 15504（SPICE）国际标准在车用领域下的修改版本。其目的是为了评估汽车产业中，电子控制器供应商开发的流程。

ASPICE 建立在 V 模型之上，它需要与每个开发阶段相对应的测试阶段。 这是一个严格的模型，需要严格的评估以确保持续的评估和发展。 下图是 ASPICE 中定义的典型开发流程：

(From: https://www.automotivespice.com/fileadmin/software-download/AutomotiveSPICE_PAM_31.pdf)

V 模型的左侧包括需求分析、系统设计、架构设计、模块设计、编码；

V 模型的右侧包括单元测试、集成测试、系统测试、验收测试。

从上面可以看出，V 模型是一种类似于瀑布式的开发模型，开发模型是线性的，制造商只有等到整个过程的末期才能见到开发成果。尽管在实际过程中，可以进一步分解成更小的任务进行验证，但阶段的划分依然比较固定，阶段之间会要求大量的文档。

敏捷开发的理念

传统装载在汽车上的软件往往一旦卖出，就不会再变更，升级需要去线下 4S 店完成。在这样的情况下，基于 V 模型进行软件开发有利于需求和过程管理，明确范围和进度。不过，这样的情况正在发生变化，一方面，消费者对新技术越来越感兴趣，特别是与用户有直接交互的信息娱乐系统或者是智能驾驶功能，用户希望功能不断的完善，获取新的技术不用换一台新车；另一方面，随着车内固件升级（FOTA）和应用软件升级（SOTA）技术的成熟，汽车制造商已经有可能在远程完成软件的更新。软件和硬件的开发过程正在逐步解耦，软件需要实现小步快跑，不断迭代。这个时候，汽车软件的新老从业者们开始思考如何改变，是否能在汽车行业中应用敏捷开发的理念或者是将敏捷开发与传统的开发模型进行结合。目标是获得效率和质量的平衡。

与传统计划驱动的开发相比，敏捷开发有两个核心理念：

1. 自适应的而不是预测的；

2. 以人为本而不是流程为导向的

计划驱动的工程期望在开发之前提出一个预测计划。该计划列出了整个项目的人员、资源和进度。软件设计也是预先完成的，预计实现与此设计一致。成功的衡量标准是发展遵循这个计划的程度。

敏捷计划是用来帮助控制变更的基线。敏捷团队的计划与传统团队一样仔细，但计划会不断修改以反映在项目中学到的东西。成功取决于软件提供的价值。

计划驱动的工程寻求一种结构以将个体差异减少到微不足道的程度。这样的工业流程更具可预测性，在人员转移时能够更好地应对，并且更容易定义技能。

敏捷工程将软件开发视为人类活动，其中涉及的人员以及他们如何作为一个团队是成功背后的主要驱动力。

持续集成

在敏捷开发的理念（原则）之下的有力实践是持续集成和持续交付（CI/CD）的软件产品（有的制造商也同样在探索硬件产品敏捷开发的可能性）。持续集成和持续交付的重要特点是自动化、不断构建，下图是敏捷开发的主要过程：

（From：https://faun.pub/most-popular-ci-cd-pipelines-and-tools-ccfdce429867）

持续集成和持续交付需要快速完成计划、编码、测试、发布的循环，持续集成和持续交付并不是画成“圆”的 V 模型，自动化的测试和自动化的发布是不可或缺的组成部分。而这一过程应用于每一次提交，意味着每一次代码的提交、合并都会经过自动化的测试，成为一个新的发布版本。为了效率的考量，可在提交合并和版本发布时，进行不同程度的测试。重要的是持续获得版本，为进一步验证和最终交付给用户提供有力支持。

为了完成这样快速的发布，CI/CD 本身也成为了一个复杂的软件产品，需要专业的软件团队进行维护，编写大量代码以实现各个任务的调度，集成多个工具链以提高整个过程的效率。而这也是汽车制造商实现敏捷软件开发转型的一个挑战。在过渡期间，往往会因为工具链的不成熟而影响产品的开发效率，甚至于忽略必要的自动化测试和反馈，使产品的质量出现问题。

代码分支模型

持续集成和持续交付的落地过程中，需要考量不少因素，包括但不限于工具链的选择、流程的制定、服务器的搭建等等，而代码分支模型的选择是持续集成团队和软件开发团队需要在早期进行定义并共同遵守的一项规范，下面将对持续集成过程中代码分支模型的选择进行探讨。

分支模型是软件开发团队通过 Git 等版本控制系统编写、合并和交付代码时采用的策略。 好的分支模型增强了软件交付过程中的协作、效率和准确性。 它定义了团队如何使用分支来实现并发开发。

良好的分支模型往往可以达到以下目标：

1. 对持续集成的良好支持；

2. 确保高频率的集成。关于高频率集成的优势，大家可以阅读Integration Frequency进一步了解。

3. 减少合并冲突和处理冲突的成本（在开发过程中，处理大量合并冲突是开发人员非常头痛的问题，并且很容易发生错误）。

比较常见的分支模型有：Git-flow、GitHub Flow、GitLab Flow 和 Trunk-based development。

在持续集成中，使用 Trunk-based development 是一个常见的选择，下面简单介绍一下各个分支模型的特点。

Trunk-based development

Trunk-based development (TBD) 是基于主干开发是一种分支模型，所有开发人员每天都将他们的更改直接集成到共享主干（trunk 或 master）中。 理想情况下，主干始终处于可发布状态。

下图说明了 TBD 的基本流程：

（From: https://trunkbaseddevelopment.com/#scaled-trunk-based-development）

基于主干开发的典型策略如下：

1. 开发基于主干，没有长期存在的功能分支（feature branch）。 如果需要功能分支，它应该是本地的或短期的，并在几天内合并到主干；

2. 主干应保持健康且可发布的状态；

3. 发布分支（release branch）从主干中“即时”检出（checkout）（例如发布前 2 周）并在发布之前冻结（例如发布前 1 周）；

4. 修复应该首先上传到主干，然后 cherry-pick 到发布分支（这有助于确保主干中包含所有修复并避免回退）。

TBD 非常适合持续集成，持续集成的流程可以在主干上运行，对每次提交进行验证，在代码成功合并后进一步生成交付物。发布分支是为了更好的管控产品的质量，因为实际过程中，尽管主干经过验证，但缺少冻结过程，新的提交容易造成意想不到的问题，发布分支的存在有效地控制了这一影响。在发布分支检出后，同样可以与主干一起进行持续集成和交付。

使用 TBD 的主要挑战是当有体量较大的新特性需要开发时，高频的集成会比较难做到，开发人员需要额外的工作（如使用标志位等方式），避免不完整的功能在产品中运行。

Git Flow

Git Flow 模型背后的主要思想是将工作隔离到不同类型的分支（main, develop, feature, release, hotfix）。 主干分支和开发分支都是长期存在的。 下图是 Git Flow 的典型流程：

（From: https://docs.gitlab.com/ee/topics/gitlab_flow.html#git-flow-and-its-problems）

虽然 Git Flow 使开发、修复、发布分支很清晰，但很难在采用 Git Flow 的工程项目上进行持续集成，main 和 develop 分支都是长期存在的，且随着时间的增加，两者可能会有越来越大的差异，难以形成自动化的集成交付闭环。

GitHub Flow

GitHub Flow 对 Git Flow 进行了改进。开发人员使用功能分支（feature branch）并定期将其功能分支推送到主干。 发布通常是直接从主干完成的。 每个开发人员都会创建一个新分支，即功能分支。 功能分支在功能完成后合并到主干。

GitHub Flow 对持续集成有良好支持的，但功能分支可能会存在较长的时间，从而影响软件集成的频度。

另外，GitHub Flow 的概念中并没有发布分支，发布直接从主干进行，会对软件的质量的管控带来更大的挑战。

GitLab Flow

GitLab Flow 在 GitHub Flow 的基础上增加了发布分支（release branch），对持续集成有良好的支持，也可以对需要发布的产品提前进行冻结以更好的管理质量。它和 TBD 的主要区别是在模型的理念上，TBD 更加鼓励高频率的代码合并和集成。

快速敏捷的软件开发流程同样正在赋能极氪软件及电子中心，使极氪能更快速、更高质量的为用户提供日新月异的软件体验。通过与传统开发模式的有效结合，利用 Gerrit、Jenkins、Zuul、Artifactory 等工具，实现高效的自动化测试和发布。

下期，我们将整理一下我们的实战经验给大家作为参考，敬请期待。

Acknowledge：

https://martinfowler.com/agile.html