经过十多年的发展，敏捷软件开发已经从一种前卫的开发方式转变成为在各大软件公司中被广泛应用的主流技术，变成了互联网行业的一种潮流。随着软件定义汽车等概念的兴起，软件在一辆汽车中的价值正在不断增加。电动化、网联化、智能化、共享化的背后都需要强大的软件能力作为支撑，而软件能力不仅体现在构建出高质量的软件产品上，同时还体现在软件产品的快速迭代以满足快速变化的市场需求的能力之上。这样的变化无疑给汽车软件开发带来了新的挑战，同时也带来了巨大的机遇。新玩家纷纷入场，期望在软件和用户体验上赢得市场，而传统的汽车制造商则正重新审视组织架构、人才、流程、职责等方方面面以期适应新的变化，成为软件驱动的公司。
持续集成/持续发布（Continuous Integration andContinuous Delivery）是敏捷软件开发中的核心过程，本文将从持续集成/持续发布角度探讨汽车软件开发过程中的代码管理和发布流程。
01 传统汽车软件的开发流程
传统汽车软件开发大量依赖于供应商，汽车制造商提出需求，由供应商负责软件编写和实现。在过去十几年的时间里，汽车电子器件的数量增长迅速，车内电子控制单元（ECU）从十几个增长到了上百个，带来的是软件复杂度的快速增加。除了汽车功能繁多所带来的软件复杂度，汽车电子类产品在软硬上往往对设备的高可靠性、稳定性有着严格的要求。这些要求在消费电子类，甚至是医疗电子类和工业控制类产品上是没有的。因此，为了满足功能安全等要求，汽车的软硬件往往需要做额外设计。面对这样的复杂系统，汽车行业制定了许多标准及方法论以规范开发过程，而在软件开发过程中，最有名的是ASPICE（Automotive Software Process Improvement and CapabilitydEtermination）。
Automotive SPICE简称ASPICE，是ISO/IEC 15504（SPICE）国际标准在车用领域下的修改版本。其目的是为了评估汽车产业中，电子控制器供应商开发的流程。
ASPICE 建立在 V 模型之上，它需要与每个开发阶段相对应的测试阶段。这是一个严格的模型，需要严格评估以确保持续的评估和发展。下图是ASPICE中定义的典型开发流程：
From: https://www.automotivespice.com
V 模型的左侧包括需求分析、系统设计、架构设计、模块设计、编码；
V 模型的右侧包括单元测试、集成测试、系统测试、验收测试。
从上面可以看出，V模型是一种类似于瀑布式的开发模型，开发模型是线性的，制造商只有等到整个过程的末期才能见到开发成果。尽管在实际过程中，可以进一步分解成更小的任务进行验证，但阶段的划分依然比较固定，阶段之间会要求大量的文档。
02 敏捷开发的理念
传统装载在汽车上的软件往往一旦卖出，就不会再变更，升级需要去线下4S店完成。在这样的情况下，基于V模型进行软件开发有利于需求和过程管理，明确范围和进度。不过，这样的情况正在发生变化，一方面，消费者对新技术越来越感兴趣，特别是与用户有直接交互的信息娱乐系统或者是智能驾驶功能，用户希望功能不断完善，获取新的技术不用换一台新车；另一方面，随着车内固件升级（FOTA）和应用软件升级（SOTA）技术的成熟，汽车制造商已经有可能在远程完成软件的更新。软件和硬件的开发过程正在逐步解耦，软件需要实现小步快跑，不断迭代。这个时候，汽车软件的新老从业者们开始思考如何改变，是否能在汽车行业中应用敏捷开发的理念或者是将敏捷开发与传统的开发模型进行结合。目标是获得效率和质量的平衡。
与传统计划驱动的开发相比，敏捷开发有两个核心理念：
1. 自适应而不是预测；
2. 以人为本而不是流程为导向的。
计划驱动的工程期望在开发之前提出一个预测计划。该计划列出了整个项目的人员、资源和进度。软件设计也是预先完成的，预计实现与此设计一致。成功的衡量标准是这个计划的遵循程度。
敏捷计划是用来帮助控制变更的基线。敏捷团队的计划与传统团队一样仔细，但计划会不断修改以反映在项目中学到的东西。成功取决于软件提供的价值。
计划驱动的工程寻求一种结构以将个体差异减少到最低。这样的工业流程更具可预测性，在人员转移时能够更好地应对，并且更容易定义技能。
敏捷工程将软件开发视为人类活动，其中涉及的人员以及他们如何协作是成功背后的主要驱动力。
03 持续集成
在敏捷开发的理念之下，持续集成和持续交付（CI/CD）软件产品（有的制造商也同样在探索硬件产品敏捷开发的可能性）。持续集成和持续交付的重要特点是自动化、不断构建，下图是敏捷开发的主要过程：
（From：https://faun.pub/most-popular-ci-cd-pipelines-and-tools-ccfdce429867）
持续集成和持续交付需要快速完成计划、编码、测试、发布的循环，持续集成和持续交付并不是画成“圆”的V模型，自动化的测试和自动化的发布是不可或缺的组成部分。而这一过程应用于每一次提交，意味着每一次代码的提交、合并都会经过自动化测试，成为一个新的发布版本。为了保障效率，可在提交合并和版本发布时，进行不同程度的测试。重要的是持续获得版本，为进一步验证和最终交付给用户提供有力支持。
为了完成快速发布，CI/CD本身也成为了一个复杂的软件产品，需要专业的软件团队进行维护，编写大量代码以实现各个任务的调度，集成多个工具链以提高整个过程的效率。而这也是汽车制造商实现敏捷软件开发转型的一个挑战。在过渡期间，往往会因为工具链的不成熟而影响产品的开发效率，甚至于忽略必要的自动化测试和反馈，使产品的质量出现问题。
04 代码分支模型
持续集成和持续交付的落地过程中，需要考量不少因素，包括但不限于工具链的选择、流程的制定、服务器的搭建等等，而代码分支模型的选择是持续集成团队和软件开发团队需要在早期进行定义并共同遵守的一项规范，下面将对持续集成过程中代码分支模型的选择进行探讨。
分支模型是软件开发团队通过Git 等版本控制系统编写、合并和交付代码时采用的策略。好的分支模型增强了软件交付过程中的协作、效率和准确性。它定义了团队如何使用分支来实现并开发。
良好的分支模型往往可以达到以下目标：
1. 对持续集成的良好支持。
2. 确保高频率的集成。
3. 减少合并冲突和处理冲突的成本（在开发过程中，处理大量合并冲突是开发人员非常头痛的问题，并且很容易发生错误）。
比较常见的分支模型有：Git-flow、GitHub Flow、GitLab Flow和Trunk-based development。
使用Trunk-baseddevelopment是持续集成中常见的选择，下面简单介绍一下各个分支模型的特点。
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更加鼓励高频率的代码合并和集成。
