前言

在汽车、芯片、工业设计等行业中，广泛用到了MATLAB和Simulink来进行设计和模拟。但是，在实际的开发过程中，咱们会遇到以下问题：

1. 汽车设计中，如何使用流水线来确保每次提交的设计文件符合ISO26262标准？
2. 每次提交之后需要手工测试，好麻烦。如何进行自动的测试？
3. 如何使用一个流程化的方式来对于模型进行评审，而不是手工发邮件？

在互联网和软件等领域，广泛使用的DevOps的思想其实已经给出了答案：使用持续集成。而极狐GitLab的流水线可以跟任何的命令行结合，所以也可以跟MATLAB结合出持续集成流水线；那么，使用GitLab流水线有什么样的好处呢？以下是一些显而易见的好处：

1. 提交之后自动CI并进行检查，把设计问题扼杀在萌芽中，最大程度减少对主干影响导致的返工，降低成本。
2. 极狐GitLab的DevOps开放式设计，可以跟几乎所有的CLI集成：demo中我们调用MATLAB命令行来进行Model Advisor检查、测试等。
3. MATLAB的模型测试结果，可以作为单元测试结果反馈到GitLab中。
4. DRY思想，把一切能够自动化的内容都自动化，可以极大程度降低设计人员的心智负担。
5. 父子流水线，对于多模型的情况，更新模型之后自动识别被更新的模型，使得只对对应的模型进行测试，更快的流水线。

流水线概念、应用、细节定义

我们以汽车里面的定速巡航（CC, Cruise Control）系统为例，讲讲如何通过GitLab CI更好的实现其模型的更改。

重要概念

1. 定义.gitlab-ci.yml，使用自动化流水线，每次提交之后自动检测。
2. 定义一个可以跑matlab应用的runner，可以使用安装了matlab的机器，也可以使用matlab的镜像。

流水线应用

你可能会问了，我们定义了流水线之后，又有什么好处呢？我们下面展示流水线的应用，其流程如下。总共通过3个步骤来展现：

1. 某个用户的分支提交之后，自动触发CI

此处使用了CI的自动提交即检查的能力，通过自动化的流程确保每一次的模型都能够通过测试，减少对人的依赖。其流水线截图如下：

测试下来发现targetSpeedThrottle模型有问题，流水线的报错会通过邮件等方式发送通知给用户。

2. 本地更新

用户发现报错邮件之后，检查报告，并在本地进行重现和修改。修改成功之后，再进行提交。

2.1 在流水线的制品中，可以看到详细的报告，以及修改建议：

2.2 在本地也重现了同样的问题：

2.3 本地修改模型：

注意修改之后再本地跑一次测试，可以看到测试均通过：

3. 提交并重新跑CI

3.1 提交并上传代码，自动触发CI

注意CI是自动触发的，可以减少程序员的心智负担。

3.2 新的CI结果

可以从下图中看到CI已经通过，此时就可以提交合并请求。

3.3 合并请求评审

当CI通过之后，用户可以通过合并请求对自己的提交进行合并。由于在v模型中模型设计很重要，此时，建议使用强制审核，使得用户的设计能够再次得到专家评审，保持主干的干净。

另外，极狐的评审还可以分不同的角色来进行审核，进一步减少审核时的人工操作。

• 有可能以前是通过一个邮件，附上模型文件，主送2个QA，1个前端，3个后端；
• 现在可以直接通过一个预定义好的合并请求，在每次合并请求的时候自动提醒不同角色的评审，通过规范化流程来保证质量。

流水线细节定义

当你了解了前面的流程之后，是不是想要立刻马上赶紧自己建立一条流水线了？那么就可以参考咱们的流水线细节定义，来定义一个自己的流水线！

本章中你会学到：

• GitLab-CI流水线：通过yaml定义
• 调用MATLAB命令行即可以进行测试（镜像（需要单独license）、本地（可以用本机或者公共机器））

1. 使用流水线自动测试

每次提交模型之后自动进行模型检查、测试、打包、部署。

有可能之前大家都是使用手工命令的方式来检查，但是这个既比较耗时，又容易出错。那么有什么可以减少耗时、减少重复操作、自动更新的方式呢？可以通过GitLab的CI，每次提交之后自动调用命令行来进行检查。其步骤如下图所示：

2. 定义流水线-父子流水线

流水线可以通过GitLab-CI，即通过yaml的方式来定义。为了解决多个模型的变化问题，采取了父子流水线。可以看下面.gitlab-ci.yml的定义有以下特点：

• 有4个子流水线
• 子流水线通过trigger.include关键字来确定子流水线需要触发的具体步骤
• 子流水线通过rules.changes来定义只有哪些文件变化时才会触发子流水线

stages:
  - Child pipelines

driverSwRequest_pipeline:
  stage: Child pipelines
  trigger:
    include: .driverSwRequest-gitlab-ci.yml
    strategy: depend
  rules:
     - changes:
        - Design/DriverSwRequest/**/*
        - .driverSwRequest-gitlab-ci.yml
        - .gitlab-ci.yml
        - tools/**/*

cruiseControlMode_pipeline:
  ...
targetSpeedThrottle_pipeline:
  ...
crs_controller_pipeline:
  ...

而父子流水线相互之间的作用，就是一个触发-反馈结果的调用，使得流水线更加结构化。其结果如下所示：

3. 定义流水线-子流水线

每个模型都有它的子流水线，而每个模型的子流水线调用了MATLAB命令行。下面我们以其中一个模型的子流水线为例，有如下的定义：

# 定义步骤
stages:
  - Verify
  - Testing
  - Package
  - Deploy

# 通过 Model Advisor 检查模型
DriverSwRequestMA:
  stage: Verify
  tags:
    - testci
  script:
    - matlab -nodisplay -batch "openProject('CruiseControlExample.prj'); DriverSwRequestModelAdvisor;"
  artifacts:
    when: always
    paths:
      - $LOGS_PATH/logs/
      - ./Design/DriverSwRequest/pipeline/analyze/**/*

# This job runs the unit tests defined in the collection
DriverSwRequestTest:
  stage: Testing
  ...

# 将前面几个步骤的结果打包
DriverSwRequestPackage:
  stage: Package
  ...

# 部署
DriverSwRequestDeploy:
  stage: Deploy
  ...

可以看到：

• 每个子流水线可以进行独立的定义。
• 每个stage都可以通过script调用命令行，所以这里除了matlab，也可以满足其它命令行工具。
• 比如Verify过程中，直接调用了DriverSwRequestModelAdvisor，而这个脚本调用了ISO26262的检查。
• 通过artifacts来定义和存储报告，这样每次流水线的报告都保存在系统中

总结

极狐GitLab自动化MATLAB和Simulink的流水线，极大方便了汽车、芯片、工业设计的代码检查，通过自动化流水线的方式在每次提交之后自动验证，减少返工率，同时也减少了重复操作。

同时，使用极狐的合并请求的审核能力，使得所有的模型在合入之前的审核变得so easy，摒弃掉使用email的耗时耗力的方式，同时规范化评审的流程。

如果需要详细流水线，可以参考该代码仓库链接