三、持续集成与交付
3.1 自动化编译框架
在智能座舱软件中，分为上层应用软件和底层软件。有些上层应用软件是与指令集平台无关的，例如Java应用程序等，它们对所运行的CPU平台没有依赖性，可以很好的适配当前平台进行执行。而在底层软件，包括操作系统，驱动程序，乃至中间件等，都与CPU指令集架构强绑定。
智能座舱域控制器所使用的SOC各有不同的指令集架构。有些SOC的CPU是x86架构，其余大部分是ARM架构。在SOC上运行的操作系统和底层软件，需要采用适应本平台的指令集进行编译，得到可运行的二进制代码。获得这些软件的二进制执行程序的过程，称为编译。
编译的过程如下图所示，C代码源文件(.c)通过编译器，生成二进制目标文件(.o)。所谓的.o文件只是编译过程中间所生成的过渡性文件。多个.o文件通过链接器，链接生成可执行的二进制映像文件(.axf)。这个二进制映像文件包含了执行代码(.bin)和可供调试分析的debug信息(.txt)。
在程序开发阶段，.axf文件是软件工程师调试分析问题所必不可少的；当软件成熟并可进行发布以后，去除.txt 调试信息，只保留.bin 执行代码就可以了，这样可以节省大量的程序存储空间。
对于大量使用ARM架构的座舱SOC来说，在PC机上进行程序开发，生成二进制映像程序后再下载到SOC上运行是非常自然的行为。这其中的原因在于PC机软件上具有大量的IDE(集成开发环境)软件，对于程序员非常友好。而在ARM 机器上，通常只能使用命令行工具来对软件源代码进行编辑、编译，并且执行效率也远远不及PC机或者服务器。因此，这种在A机器进行代码编辑和编译，生成二进制执行程序后运行在B机器上的行为，称为交叉编译。
座舱SOC所使用的操作系统，无论是Linux，QNX，还是Android，都提供了完整可用的交叉编译工具链。以Android为例，它主要包含：
- arm-linux-androideabi-gcc：这是用于编译ARM架构下C代码，生成目标文件(.o)的编译器。
- arm-linux-androideabi-ld：这是用于将编译后的目标文件(.o)链接成可执行文件的链接器。
- arm-linux-androideabi-as：这是用于将汇编代码编译生成目标文件的汇编器。
- arm-linux-androideabi-g++：这是用于编译C++代码的编译器。
以上这些工具程序，包含在Android开发包NDK (Native Development Kit) 中。它们是一些二进制的可执行文件，通常会被IDE或者命令行输入的命令所调用。事实上，这些编译工具链由ARM公司提供。
自动构建系统
一个可用的智能座舱软件平台，通常包括成千上万的源代码程序。这些.c, .cpp, .s 源代码文件，按逻辑功能划分，放置在不同的目录结构下。那么如何才能方便快捷地通过一个操作命令，就能编译生成所需的可执行文件呢？操作系统的开发者(既包括Google等商业公司，也包括Linux社区等开源项目)，早就准备好了对应的自动构建系统。
- GNU Make：GNU Make是基于Makefile的构建工具，它通过编写Makefile脚本来描述构建过程。它支持多种操作系统和编译器，但由于是Unix系统的传统工具，在一些非Unix系统上可能会有兼容性问题。在Android 7.0之前，Google使用GNU Make来管理自动编译和构建。
- CMake：CMake是开源的跨平台工具系列，可以用于构建、测试、打包软件，支持多种操作系统和编译器。它通过编写CMakeLists.txt文件来描述构建过程。
- Clang/LLVM：LLVM则是一个独立的开源项目，提供了可扩展的编译、链接等工具链，支持多种平台和架构。它包括Clang等编译器，提供了LLDB等调试器，还提供了编译、链接等工具链。因为是开源项目，所以有一些独立的CPU研发项目会使用LLVM来构建自己的交叉编译工具链。
- Ninja：Ninja是一个轻量级的构建系统，使用Ninja文件作为构建脚本，专注于提高构建速度。在Android7.0之后，Google认为 GNU Make编译缓慢、容易出错、不可扩展且难以测试，因此引入了Ninja构建系统，该系统通过.ninja文件实现了Android构建系统的灵活性，因为.ninja文件是人类可读的。
- Soong：Soong是Android平台上的构建系统，用于编译和管理Android源代码。它使用Makefile作为构建脚本。在Soong编译系统中，每个模块都有一个相应的.mk文件，其中包含了该模块的编译规则和依赖关系。Soong读取这些.mk文件，并按照其中的规则和依赖关系生成.ninja。对于复杂的.mk文件(如Android.mk)，Soong还会使用到一些工具来辅助编译过程，例如kati和ckati工具可以将.mk/Makefile文件转换为.ninja文件。
Android自动化编译框架
既然智能座舱使用的操作系统以Android，QNX，Linux为主，而Android无疑是最为复杂，且变化最快，迭代最多的系统，那么我们将以Android为例，简要讲述其自动化编译架构：
- 使用Kati工具，从复杂的Android.mk或其他Makefiles生成out/build-aosp_bluejay.ninja文件。
- 对于简单的Android.mk文件，Soong会生成Android.bp；而后生成out/soong/build.ninja文件。此外，还会生成一个较小的out/combined-aosp_bluejay.ninja文件，负责将两者连接起来，作为执行入口。
- 最终，Ninja文件是真正直接控制源代码编译的工具，负责生成apk、aar和dex文件。APK的签名也是使用ninja规则完成的，然后完成这一切后，会创建*.img文件。
对于Android命令行工具来说，要编译完整的可执行文件，只需要输入如下3步命令：
- 运行source build/envsetup.sh : 该命令执行envsetup.sh脚本，可以设置Android产品的各函数，例如lunch就是生成的shell函数。
- 选择lunch选项：执行envsetup.sh中生成的lunch()函数，用于构建映像文件和其他构件(apk, jar, so等)的环境，以适配多项目的需求。每个项目都是lunch()函数的一个参数。
- 运行make <module-name>或m <module-name>
在Android N之前：
m或make命令相当于make -f build/core/main.mk（通过GNU make构建）
在Android N之后：
m或make命令相当于build/soong/soong_ui.bash -make-mode，这意味着soong_ui.bash是Android平台构建系统的核心。
3.2 持续集成
概念
持续集成 (CI, Continuous Integration) 是指在开发人员将代码频繁地提交到版本控制系统后，通过自动化构建、测试和部署操作，及时发现并解决代码错误，以保证软件的稳定性和可靠性。
持续交付 (CD, Continuous Delivery) 则是在持续集成的基础上，通过不断地自动化流程，实现软件交付过程的自动化，以优化软件交付的时间，并减少人为错误，提高软件的质量和可靠性。
步骤
汽车软件全景图对持续集成所包含的内容总结如下图：
图片来源：汽车软件全景图(2022)
而持续集成的核心，集中在代码提交之后的自动化测试流程上。
典型的持续集成流程，大致可以总结为以下步骤：
代码提交 --> 触发持续集成流程 --> 提交前测试 --> 自动构建 --> 代码提交
- 代码提交：通常需要使用强大的代码管理软件，比如，在Linux环境下，许多公司都采用了git系统。一些常用的代码管理工具还有SVN，ClearCase等。
- 提交前测试：在多人协作的开发环境中，有些公司的持续集成策略规定：每一个工程师在提交代码前，系统都应自动执行静态代码检测和预编译功能。静态代码检测通常会选用优秀的工具，对新增代码的逻辑调用关系，参数设置，内存分配，语法规范等进行扫描，如果检测出问题，则本次代码提交即被终止。这样可以有效避免多人协同工作时，由于单个人的疏忽而影响到整个系统的及时交付。
- 自动构建：系统调用自动编译命令，生成可执行的程序。并通过自动化测试平台，将程序下发到被测试车机中进行自动验证。
- 代码提交：当自动构建顺利通过后，新代码才会真正提交到代码仓库中。代码管理工具会为提交操作生成记录和确认依赖关系。
持续集成工具
持续集成常见的工具有：
- Jenkins：是当今最常用的持续集成工具之一，基于开源持续集成服务器，使开发人员可以更快地构建、自动化和测试任何软件项目。
- Buddy：是基于Web的、自托管的持续集成（CI）和持续交付（CD）工具，也称为Buddy.Works。
- Travis CI：是基于云的平台，用于在软件开发过程中提供持续集成和持续交付的服务。
Jenkins是一种开源的自动化服务器，用于帮助软件项目进行自动化构建、测试和部署。以下是Jenkins的一些主要特性和功能：
- 持续构建和测试：Jenkins可以持续地监控代码的更改，并在代码发生改变时自动构建和测试项目。
- 集成到版本控制：Jenkins可以与版本控制系统（如Git）紧密集成，以便在代码发生更改时自动触发构建和测试流程。
- 自动化部署：Jenkins可以帮助自动化部署过程，包括将应用程序打包为可执行文件、将打包好的应用程序部署到生产环境等。
- 监控应用程序性能：Jenkins可以集成各种监控工具，如New Relic、Dynatrace等，用于实时监控应用程序性能。
- 多种插件支持：Jenkins拥有庞大的插件生态系统，可帮助用户扩展其功能，以满足各种特定的构建、测试和部署需求。
- 分布式构建：Jenkins可以轻松处理分布式构建，以便在多个计算机上同时进行构建和测试，从而加快构建速度。
3.3 持续交付
CI/CD通常是一个完整的过程，如果要对二者进行特别区分的话，那么持续集成是一种软件开发实践，旨在促进团队成员频繁地将代码提交到代码仓库，并通过相关的自动化测试手段进行测试验证，以减少问题和解决问题。它的主要目标是提高开发人员的工作效率以及整个IT团队的效率。
持续交付则是持续集成的后续动作，涵盖了软件交付生命周期的大部分环节，包括软件从开发到部署、再到给用户使用的整个过程。它关注的是如何通过自动化流程将经过测试的软件快速部署到生产线环境，并将最新的应用交付给用户端，旨在实现软件的快速交付。
具体来说，持续交付中包含的环节有：
- 自动构建：用自动化的方式替代传统的手工编译和测试，保证代码的质量。
- 打包：将代码进行封装，使其易于管理和运输。
- 部署与测试：通过自动化的方式进行部署和测试，以确保软件可以在不同的环境中正常运行。
因此，持续交付和持续集成的区别在于：持续集成关注的是构建，即如何将代码编译、测试并打包成可运行的程序；而持续交付关注的是部署，即如何将已经测试过的软件包快速、可靠地发布到生产环境中，提供给用户使用。
下图是持续交付的主要内容：
图片来源：汽车软件全景图(2022)
相对于上一小节的持续集成流程图来说，持续交付增加了提交后测试以及产品部署的验证环节，如图所示：
对于持续部署来说，主流的工具仍然是Jenkins。它在持续集成和持续部署的工作流程上的主要区别如下：
持续集成（CI）工作流程：
- 开发者将代码提交到版本控制系统（如Git）。
- Jenkins监视版本控制系统，检测到新提交的代码后，自动从版本库拉取代码。
- Jenkins执行自动化测试，如单元测试、集成测试等。
- 如果测试通过，Jenkins将代码合并到主干或进入下一步流程；如果测试失败，则通知开发者并记录错误信息。
- 代码合并后，Jenkins会自动触发构建过程，生成可部署的代码。
- Jenkins运行自动化构建脚本，如编译代码、安装依赖、配置资源等。
- 构建完成后，Jenkins会再次执行自动化测试，验证部署包的正确性。
- 如果构建成功并且自动化测试无误，Jenkins会通知开发者并发布新版本。
持续部署（CD）工作流程：
- 在云端管理软件上，Jenkins监视版本控制系统，一旦发现新提交的代码，自动从版本库拉取代码。
- Jenkins执行自动化测试、构建过程与持续集成一致。该过程在云服务器上执行。
- 构建完成后，Jenkins会通过台架软件，自动将代码部署到被测试车机软件上。
- Jenkins会监控被测车机中的应用程序表现，定时检查是否有错误或异常。
- 如果发现错误或异常，Jenkins会回滚部署包并通知开发者。
总结来说，持续集成和持续部署在Jenkins的工作流程中，最大的区别在于持续部署流程中增加了自动将代码部署到测试车机的步骤。同时，Jenkins在持续部署中需要具备更多的监控和回滚能力，以确保被测车机中的应用程序能够稳定运行。
参考文献
- 《中国汽车基础软件发展白皮书3.0》
- 《汽车软件全景图(2022)》
- Android 编译系统(Build System)剖析_Calvin880828的博客-CSDN博客