关于持续集成与基于模型的设计的分析和应用

持续集成（Continuous Integration）在纯软件开发中是一个比较通用的实践：

持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试)来验证，从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题。

持续集成通常伴随着以下几个部分：

和版本管理工具友好集成

编译自动化

测试自动化

例如，张三开发了一个新功能，他所在的版本开发分支为Testing。他在提交代码后（当然自己需要先测试一下），系统可以自动编译，并运行回归测试用例。在确定功能稳定可用后，Testing分支可合并到主分支。

大部分MBD（基于模型的设计，Model-Based Deisgn）客户都已经比较好地使用了版本管理工具，例如SVN或者Git。很多客户也能开发一些MATLAB脚本做一些自动化编译，例如：

使用Embedded Coder自动产生算法层C代码，将C代码自动拷贝到TI的CCS工程和驱动部分代码整合，然后自动调用CCS的编译功能进行编译链接产生最终二进制文件，此后可以将二进制文件自动下载到开发板芯片中编译执行。

MBD之所以为一种开发效率高的开发模式，用户会将主要精力集中于Model-In-the-Loop（MIL）的开发。在MIL层面，用户会开发大量的单元测试用例，在和用户的讨论中发现，有一种场景比较实用：

提交模型+自动回归测试+自动报告生成

本文以Git、GitLab、Jenkins为主要工具，介绍如何配置MBD模式下的自动回归测试+自动报告生成。

详细配置

注意：通常情况下，Jenkins Server会选择一个计算能力较强的服务器，本文为了方便选择将Simulink和Jenkins装在同一机器上。

1. GitLab的项目创建

先在GitLab下建立一个项目，本地Git和GitLab Server可以选择SSH连接也可选择HTTPS方式，本文选择HTTPS。

然后在本地的Simulink工程目录，打开Git Bash。

>> Git init

>> Git clone https://insidelabs-git.mathworks.com/mozhou/SBR.git

2. Simulink和Git集成

本文中，Git可视为GitLab的客户端。Simulink可以直接在界面中，进行Git的操作，见下图：

建议直接用Git命令行操作，优势如下：

Git命令行灵活方便，易于脚本化。

想要熟悉Git命令，自己最好从头开始，用Git init、Git add、Git commit、Git push把Simulink工程中的文件添加到GitLab Server。也可理解一个Simulink工程中哪些文件是永久文件（需要添加到版本库），哪些是中间文件（不需要添加到版本库）。

Simulink是比较智能的。

一旦你用手动方式做了一遍Git操作，Simulink就自动“记得”哪些文件和Git库是有关联。

3.Jenkins的配置

首先，安装Jenkins时候装上必用的几个plugin ：Git plugin、GitLab plugin、GitLab Hook plugin。然后在Jenkins里面建立项目。

配置源代码GitLab仓库设置

配置BuildTrigger

在GitLab的项目的settings -> integrations:

加上webhook后可以测试一下。

然后回到Jenkins的项目设置：

配置编译脚本：

runMyTests.m 是一个MATLAB脚本，它的功能就是将指定位置的测试用例找到，然后批量执行所有回归测试用例，最后输出指定格式的报告。

3. 运行

打开模型

浏览测试用例：测试用例一共有6个

编辑模型后，提交到GitLab。

在Jenkins上编译成功，查看编译和测试报告。

在实际的工程项目中，随着项目和人员的扩展，越来越多的开发人员会利用合适的代码版本管理和持续集成工具进行并行开发。Git、GitLab、Jenkins这个组合适用于任意大小规模的持续集成开发模式。持续集成也是敏捷开发的一个最佳实践。而MBD的模式——早期验证、虚拟集成完全符合敏捷开发的理念。越来越多的开发人员在使用MBD的同时也关注如何拥抱敏捷开发。