工作思考 —— 快速迭代

最近一段时间，领导希望我们在部门内搭建一个控制器软件持续集成（CI）的一个网络服务器。我的第一想法是什么是持续集成？根本没有听说过啊？带着这个想法我试着查询了下“持续集成” 与 “持续交付”。

持续集成（Continuous integration）是一种软件开发实践，即团队开发成员经常集成他们的工作，通过每个成员每天至

少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验

证，从而尽早地发现集成错误。

持续交付（Continuous Delivery）是一系列的开发实践方法，用来确保让代码能够快速、安全的部署到产品环境中，它通

过将每一次改动都提交到一个模拟产品环境中，使用严格 的自动化测试，确保业务应用和服务能符合预期。

对于汽车控制器软件而言，编译和集成经常花费了集成工程师大量的时间。在IT公司一般是多个人集成一版本软件，而对于汽车软件集成工程师更多是一个人集成多版软件。相比于持续集成，我们更关心持续编译，不要在封闭接口上浪费大量的时间，简单的编译错误让服务器自己去搞定吧。但持续集成依旧可以给我们汽车软件带来以下好处：

（1）协同合作。对于pilot平台项目开发的阶段，往往是许多工程师对一版软件负责。每个人近乎每天都要对软件进行升级，而每次升级都会触发一次集成。对于编译报错的地方进行及早修复，减少后期集成周期。现如今，客户的软件开发水平越来越高。客户要求参与软件开发的请求也越来越多，和客户协同开发也是供应商日后的常态。

（2）环境统一。有时候常听到同事抱怨。为啥同样一版软件在你的电脑能编过，在我的电脑就编译报错。编译环境的统一，能减少因为电脑环境原因带来的一些问题。

（3）编译速度。服务器的编译速度，往往比工程师自己的电脑要强得多。此外由于工具链安装在服务器端，工程师再也不用安装那些复杂又繁琐的工具链了。

（3）自动化测试。对于嵌入式软件来说，可以增加代码的静态测试比如QAC测试等。

说到底，持续集成与持续编译，都是一种快速迭代思想的体现，都是为了加快软件释放的速度去进行测试。如果测试工程师能在软件释放前尽早的拿到测试软件，就能更早的进行测试，更早的发现其中潜藏的bug。因为当软件规模达到一定程度时，一些bug仅仅靠review code 经常也是无法发现的，这时候只能依靠测试这最后一道关卡了。测试的时间越长，软件质量的可靠性越高。

其实在汽车软件的基于模型的设计中（MBD，model - based - design）中是推荐在嵌入式软件开发中使用快速迭代的思想的。

（1）modeling and simulation

（2）continuous and verification

（3）rapid prototyping

（MBD方式的工作流程）

快速原型开发多运用在控制器开发的早期阶段，而模块的建模仿真应该是现在使用的比较多的方式，第三步持续的验证与测试这块内容则又相对缺乏，而持续集成与自动化测试正是对这块的一个补充。但这涉及到相对专业的工具链的开发、测试脚本的编写、网络服务器的维护等对汽车软件工程师相对不擅长的领域，但这都不是根本问题。

反而感到惊讶的是，持续集成这么优秀的一种软件开发方法，竟然现在才传入部门，而且知道的还只是个名字。而即使是一个小小的初创的IT团队都已经开始使用这种的软件开发方法，这不禁让人深思。

对于控制器供应商关注的是软件质量，他们更在乎的是稳定。无论是代码的稳定，工具链的稳定，甚至开发、测试方法的流程与方法的稳定。的确，不更改就不容易犯错。当然这是一个优势，也是一个弊端。其中一个很大弊端就是对新事物、新方法的接纳程度要比外界慢的不止一个档次，比如更先进的软件开发流程、新工具运用、自动化测试、机器学习以及大数据等。

对于IT公司而言，持续集成和持续交付无疑是对快速迭代思想的体现，软件版本的升级远比前者来的更加频繁。在不断的测试，尽早尽快的暴露自己系统漏洞。而他们对先进技术的接受以及运用的速度本来就比我们要快得多，也许这就是Spacex始终认为自己是一个科技公司的原因吧。

预告

随着功能安全在汽车电子方面的逐步深入，OEM对功能安全的要求也越来越严苛。后续大圣将邀请一位同事来介绍下ISO26262的相关基础知识。敬请期待！

工作思考 · 目录

下一篇·工作思考 —— ASPICE