车载软件架构 —— 持续集成持续交付我是穿拖鞋的汉子，魔都中坚持长期主义的汽车电子工程师。老规矩，分享一段喜欢的文字，避免自己成为高知识低文化的工程师：“

对学习而言，学习之后的思考、思考之后的行动、行动之后的改变更重要，如果不盯住内层的改变量，那么在表层投入再多的学习量也事倍功半，因此从权重上看，改变量＞行动量＞思考量＞学习量。

”

图片

本文主要-> 1、持续集成持续交付概述-> 2、持续集成-> 3、持续交付一、持续集成持续交付概述CI/CD 是一种通过在软件开发阶段引入自动化来频繁向客户交付软件的方法。CI/CD 的核心概念是持续集成、持续交付。作为一个面向开发、测试和发布团队的解决方案，CI/CD 预先解决了新代码集成过程时可能引发的问题。CI/CD 可让持续自动化和持续监控贯穿于软件的整个生命周期（从集成和测试阶段，到发布和部署）。这些关联的事务通常被统称为 "CI/CD 管道 "，由开发、测试和发布团队以敏捷方式协同支持。实际上，CI/CD 在传统 IT 行业早已风靡多时，但汽车行业相比于传统 IT 行业有一定差异性，导致了车载软件的开发过程中，CI/CD 的流程和标准会有所不同。具体的区别，例如，车载软件的 CI/CD 流程会比传统的 CI/CD流程稍微短一点，CD的过程只有到持续交付这个环节，CI使用的静态检查和自动化测试的范围和工具会更针对汽车行业标准。总的来说，差异性体现在下面这两方面：-> 车载软件多数是嵌入式软件的开发与传统软件的 CI/CD 不同，车载软件开发大部分是嵌入式开发，整个过程需要严重依赖硬件，而如今随着汽车电子电气架构变得越来越复杂，会有更多的硬件、软件以及更多的连接，而硬件以及连接也是传统 CI/CD 中从未遇到过的难题。-> 车载软件对质量和安全要求更高相比于传统 IT 行业，汽车电子对软件和硬件的质量和要求都非常高，这些要求在消费电子类，甚至是医疗电子类和工业控制类产品上是没有的。而为了满足功能安全等方面的要求，汽车软件往往需要做一些额外设计。面对这样的复杂系统，开发人员也需要比传统开发更现代、更强大的软件开发流程、开发环境以及开发工具。二、持续集成持续集成（CI）是指频繁地（每天至少一次）将代码集成到主干。它的好处主要有两个：-> 快速发现错误。每完成一点更新，就集成到主干，可以快速发现错误，定位错误也比较容易。-> 防止分支大幅偏离主干。如果不是经常集成，主干又在不断更新，会导致以后集成的难度变大，甚至难以集成。正如行业前辈所说：

持续集成并不能消除 Bug，而是让它们非常容易发现和改正。

持续集成（CI）开发人员将会频繁地向主干提交代码，这些新提交的代码在最终合并到主干前，需要经过自动化集成、静态代码解析和自动化测试流进行验证。 持续集成（CI）是在源代码变更后自动检测、拉取、构建和（在大多数情况下）进行单元测试的过程。它的目标是快速确保开发人员新提交的变更是好的，并且适合在代码库中进一步使用，这样有助于降低总体的构建成本，并在开发周期的早期发现缺陷。而对于bug，越前期发现，修复的代价就越低！1、持续集成流程

图片

典型的持续集成流程，大致可以归结为以下4个步骤：A、提交代码到代码仓库；B、触发持续集成；C、进行代码静态检查 -> 自动集成 -> 提交前的自动化测试 -> 提交后的自动化测试；D、结果反馈。2、代码管理代码管理是 CI/CD 流程中不可或缺的一部分，代码管理包含了版本管理和代码审核两部分，版本管理方式决定了是否能够实践 CI/CD 以及 CI/CD 的实践策略。目前比较常用的版本管理工具有 GIT、SVN、RTC 等，这些工具可以方便 CI 针对不同的分支和版本制定不同的集成和检查策略。如图所示，在代码管理部分，目前比较主流的做法是：针对不同的分支和主干，采用不同的策略，包括触发策略和审查策略。（1）在触发策略上，对于个人分支，可以采用提交触发的方式，即该分支上每次的提交都会触发检查，主要检查本次提交的代码本身有没有问题；而在集成分支上，一般则采用定时触发或合并触发方式，即设定固定的触发时间或每次有新的合并时才去检查，这部分则主要检查本次合并过来的代码是否会对原来的代码造成影响。（2）在审查策略上， 同样建议按分支来划分，对于个人分支部分，主要进行代码本身的静态、动态测试等；而对于集成分支，除了静态、动态的测试，往往还需要集成测试、系统测试等。当然，在代码集成时，除了自动化的测试审查外，还建议引入人工审查，以最大程度保证代码的质量.

图片

目前，市面上也有很多基于GIT的优秀工具，比如Github、Gitlab、Gerrit等，这些工具集成了版本管理、代码审核等基本功能。有了这些工具，再配合合适的分支模式（主干开发模式、Git-Flow 模式、GithubFlow 模式、Gitlab-Flow 模式等），即可方便地支撑 CI/CD 流程。3、静态检查代码静态检查可以在不需要代码运行的情况下，基于源代码层面，对源代码使用规则进行分析和检查，这可以有效的提高代码质量。一些优秀的工具可以深入到代码程序的逻辑检查、内存使用情况的检查甚至更高层面的检查，可以有效地提高代码的安全性、健壮性和运行性能。代码静态检查环节是持续集成中最常做的以及最容易实现的环节。在该环节，一般输入源代码以及检查规则，即可完成自动化的检查。而在该环节，我们还应该关注代码需要满足哪些规则，以及为何需要满足这些规则，以此来提高开发工程师的开发能力。在通常使用的静态解析工具中，开源的有 Cppcheck、Cpplint，、Findbugs、Spotbugs 等，商用的有QAC、Klocwork 等。对于一些功能安全件，有代码质量的要求，静态代码检查规则需要满足车载行业检查标准，常见的标准有 Misra C， Misra C++，对于安全编码层面，常用的标准有 Cert C，Cert C++，Cert Java 标准。商用软件能够覆盖目前的大部分检查规则。

图片

自动化集成本质上是一个自动编译和打包的验证过程，借助软件开发时使用的编译和打包工具，对源代码进行编译、链接、打包，提前发现代码编译过程中的编写问题、链接过程中的依赖问题、打包过程中的配置等问题。在汽车行业中，不同的目标平台往往需要不同的编译器，这也导致了编译器工具非常多，如常用的HighTec、Tasking、Greenhills 等。同时，车载软件的复杂性也导致了编译环境非常复杂。在持续集成（CI）中，编译过程的自动化是可以比较轻松地去实现的，而复杂的编译环境适配才是持续集成（CI）在车载软件编译环节中需要重点关注的事情。4、提交前自动化测试正如在代码管理中所说，代码管理的分支审查策略建议在代码合并到正式分支前进行自动化测试。该步骤是为了保证计划合并到正式分支的代码本身没有质量问题，这样不仅能够减少开发人员测试工作，同时还能确保软件的质量。对于这部分提交前的自动化测试，我们认为它有以下几方面的要求：（1）测试需要尽可能快地完成。提交前的自动化测试每天可能发生几次到几十次，这取决于开发人员提交代码的频率，每个开发人员每次的提交都会触发该测试，因此开发人员需要尽快得到反馈，了解本次提交的代码是否有问题，如果有就进行修复，如果没有则进行后续的开发。因此，尽可能快的测试，能够保证开发的效率.（2）测试的范围通常是单个模块，为此提交前的自动化测试的测试方法通常是采用单体测试。对于功能安全件，对测试结果有一定的要求，需要根据测试的通过率对代码的行覆盖和条件覆盖有一定的要求。该项测试可以根据具体的内容要求来设定合适的评判标准。在持续集成（CI）中，从检查策略来看，该环节的测试可以包含代码的静态、动态等环节的测试，我们可以理解为保证代码本身没有问题。而从触发方式来看，一般会采用提交触发的方式。5、提交后自动化测试相比于提交前的自动化测试，提交后的自动化测试强调的是代码合并到主干或者生产分支之后进行的测试，该环节的测试旨在验证集成进来的代码是否会对之前的系统产生影响，以减少集成完整系统后出现的问题。对于该部分测试，执行的频率相对于提交前的测试频率会比较低，但同时执行时间会比较长，测试的范围更广，因为该环节会涵盖完整的系统。而对于测试的类型，该环节往往包含了集成测试、系统测试等。对于某些功能安全件，对测试结果有一定的要求。该项测试可以根据具体的内容要求来设定合适的评判标准。在持续集成（CI）中，该部分的测试由于执行时间长、测试范围广等特点，一般触发策略会选择定时触发，时间点往往设定在资源长时间空闲的半夜去执行。一方面可以保证长时间的测试，另一方面也可以有效地利用资源。三、持续交付持续交付（CD）可以理解为是持续集成（CI）流程上的一个扩展，它是对软件交付流程的进一步的自动化，以便软件能够随时快速的安装到生产环境中。持续交付（CD）指的是，在完成持续集成（CI）的情况下，将软件进行发布，使软件随时处于一个可部署的状态，对于汽车行业中的持续发布，往往指的是将其发布到制品库中进行管理。它强调的是，不管怎么更新，软件是随时随地可以交付的。

图片

搁笔分享完毕！愿你我相信时间的力量做一个长期主义者！

图片

车载软件架构——基础软件供应商&开发工具链（二）

电子电气架构——无感刷写（Vector）协议栈方案介绍

车载软件架构——基础软件供应商&开发工具链（一）

车载软件架构 —— 闲聊几句AUTOSAR OS（十一）

车载软件架构 —— 闲聊几句AUTOSAR OS（十）

车载软件架构 —— 闲聊几句AUTOSAR OS（九）

车载诊断数据库——诊断问卷调查表与CDD关联关系

车载软件架构 —— 闲聊几句AUTOSAR OS（八）

车载软件架构 —— 闲聊几句AUTOSAR OS（七）

电子电气架构——车载DoIP通信汇总

车载软件架构 —— 闲聊几句AUTOSAR OS（六）

诊断测试工具CANoe.DiVa从入门到精通系列——开门见山

电子电气架构 —— OEM关于DTC具体实现相关见解

车载软件架构 —— 闲聊几句AUTOSAR OS（五）

车载软件架构 —— 闲聊几句AUTOSAR OS（四）

车载诊断协议 —— 诊断服务Service 11

车载软件架构 ——闲聊几句AUTOSAR OS（三）

车载软件架构 —— 闲聊几句AUTOSAR OS（二）

车载诊断协议-ISO 14229

车载诊断协议-ISO 14229 / 13400 /15765

车载软件架构——闲聊几句AUTOSAR OS（一）

电子电气架构——IP地址获取方式

本站仅提供存储服务，所有内容均由用户发布，如发现有害或侵权内容，请点击举报。