极氪软件及电子核心 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.c…)
V 模型的左侧包含需要剖析、零碎设计、架构设计、模块设计、编码；
V 模型的右侧包含单元测试、集成测试、零碎测试、验收测试。
从下面能够看出，V 模型是一种相似于瀑布式的开发模型，开发模型是线性的，制造商只有等到整个过程的末期能力见到开发成绩。只管在理论过程中，能够进一步分解成更小的工作进行验证，但阶段的划分仍然比拟固定，阶段之间会要求大量的文档。
麻利开发的理念
传统装载在汽车上的软件往往一旦卖出，就不会再变更，降级须要去线下 4S 店实现。在这样的状况下，基于 V 模型进行软件开发有利于需要和过程治理，明确范畴和进度。不过，这样的状况正在发生变化，一方面，消费者对新技术越来越感兴趣，特地是与用户有间接交互的信息娱乐零碎或者是智能驾驶性能，用户心愿性能一直的欠缺，获取新的技术不必换一台新车；另一方面，随着车内固件降级（FOTA）和应用软件降级（SOTA）技术的成熟，汽车制造商曾经有可能在近程实现软件的更新。软件和硬件的开发过程正在逐渐解耦，软件须要实现小步快跑，一直迭代。这个时候，汽车软件的新老从业者们开始思考如何扭转，是否能在汽车行业中利用麻利开发的理念或者是将麻利开发与传统的开发模型进行联合。指标是取得效率和品质的均衡。
与传统打算驱动的开发相比，麻利开发有两个核心理念：
- 自适应的而不是预测的；
- 以人为本而不是流程为导向的
打算驱动的工程冀望在开发之前提出一个预测打算。该打算列出了整个我的项目的人员、资源和进度。软件设计也是事后实现的，预计实现与此设计统一。胜利的衡量标准是倒退遵循这个打算的水平。
麻利打算是用来帮忙管制变更的基线。麻利团队的打算与传统团队一样认真，但打算会一直批改以反映在我的项目中学到的货色。胜利取决于软件提供的价值。
打算驱动的工程寻求一种构造以将个体差异缩小到微不足道的水平。这样的工业流程更具可预测性，在人员转移时可能更好地应答，并且更容易定义技能。
麻利工程将软件开发视为人类流动，其中波及的人员以及他们如何作为一个团队是胜利背地的次要驱动力。
继续集成
在麻利开发的理念（准则）之下的无力实际是继续集成和继续交付（CI/CD）的软件产品（有的制造商也同样在摸索硬件产品麻利开发的可能性）。继续集成和继续交付的重要特点是自动化、一直构建，下图是麻利开发的次要过程：
（From：https://faun.pub/most-popular…）
继续集成和继续交付须要疾速实现打算、编码、测试、公布的循环，继续集成和继续交付并不是画成“圆”的 V 模型，自动化的测试和自动化的公布是不可或缺的组成部分。而这一过程利用于每一次提交，意味着每一次代码的提交、合并都会通过自动化的测试，成为一个新的公布版本。为了效率的考量，可在提交合并和版本公布时，进行不同水平的测试。重要的是继续取得版本，为进一步验证和最终交付给用户提供无力反对。
为了实现这样疾速的公布，CI/CD 自身也成为了一个简单的软件产品，须要业余的软件团队进行保护，编写大量代码以实现各个工作的调度，集成多个工具链以进步整个过程的效率。而这也是汽车制造商实现麻利软件开发转型的一个挑战。在过渡期间，往往会因为工具链的不成熟而影响产品的开发效率，甚至于疏忽必要的自动化测试和反馈，使产品的品质呈现问题。
代码分支模型
继续集成和继续交付的落地过程中，须要考量不少因素，包含但不限于工具链的抉择、流程的制订、服务器的搭建等等，而代码分支模型的抉择是继续集成团队和软件开发团队须要在晚期进行定义并独特恪守的一项标准，上面将对继续集成过程中代码分支模型的抉择进行探讨。
分支模型是软件开发团队通过 Git 等版本控制系统编写、合并和交付代码时采纳的策略。好的分支模型加强了软件交付过程中的合作、效率和准确性。它定义了团队如何应用分支来实现并发开发。
良好的分支模型往往能够达到以下指标： - 对继续集成的良好反对；
- 确保高频率的集成。对于高频率集成的劣势，大家能够浏览 Integration Frequency 进一步理解。
- 缩小合并抵触和解决抵触的老本（在开发过程中，解决大量合并抵触是开发人员十分头痛的问题，并且很容易产生谬误）。
比拟常见的分支模型有：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…）
基于骨干开发的典型策略如下： - 开发基于骨干，没有长期存在的性能分支（feature branch）。如果须要性能分支，它应该是本地的或短期的，并在几天内合并到骨干；
- 骨干应放弃衰弱且可公布的状态；
- 公布分支（release branch）从骨干中“即时”检出（checkout）（例如公布前 2 周）并在公布之前解冻（例如公布前 1 周）；
- 修复应该首先上传到骨干，而后 cherry-pick 到公布分支（这有助于确保骨干中蕴含所有修复并防止回退）。
TBD 非常适合继续集成，继续集成的流程能够在骨干上运行，对每次提交进行验证，在代码胜利合并后进一步生成交付物。公布分支是为了更好的管控产品的品质，因为理论过程中，只管骨干通过验证，但短少解冻过程，新的提交容易造成意想不到的问题，公布分支的存在无效地管制了这一影响。在公布分支检出后，同样能够与骨干一起进行继续集成和交付。
应用 TBD 的次要挑战是当有体量较大的新个性须要开发时，高频的集成会比拟难做到，开发人员须要额定的工作（如应用标记位等形式），防止不残缺的性能在产品中运行。
Git Flow
Git Flow 模型背地的次要思维是将工作隔离到不同类型的分支（main, develop, feature, release, hotfix）。骨干分支和开发分支都是长期存在的。下图是 Git Flow 的典型流程：
（From: https://docs.gitlab.com/ee/to…）
尽管 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/agil…