持續(xù)集成（Continuous Integration）在純軟件開發(fā)中是一個比較通用的實踐：

持續(xù)集成是一種軟件開發(fā)實踐，即團隊開發(fā)成員經常集成他們的工作，通常每個成員每天至少集成一次，也就意味著每天可能會發(fā)生多次集成。每次集成都通過自動化的構建（包括編譯，發(fā)布，自動化測試)來驗證，從而盡快地發(fā)現集成錯誤。許多團隊發(fā)現這個過程可以大大減少集成的問題。

持續(xù)集成通常伴隨著以下幾個部分：

和版本管理工具友好集成

編譯自動化

測試自動化

例如，張三開發(fā)了一個新功能，他所在的版本開發(fā)分支為Testing。他在提交代碼后（當然自己需要先測試一下），系統(tǒng)可以自動編譯，并運行回歸測試用例。在確定功能穩(wěn)定可用后，Testing分支可合并到主分支。

大部分MBD（基于模型的設計，Model-Based Deisgn）客戶都已經比較好地使用了版本管理工具，例如SVN或者Git。很多客戶也能開發(fā)一些MATLAB腳本做一些自動化編譯，例如：

使用Embedded Coder自動產生算法層C代碼，將C代碼自動拷貝到TI的CCS工程和驅動部分代碼整合，然后自動調用CCS的編譯功能進行編譯鏈接產生最終二進制文件，此后可以將二進制文件自動下載到開發(fā)板芯片中編譯執(zhí)行。

MBD之所以為一種開發(fā)效率高的開發(fā)模式，用戶會將主要精力集中于Model-In-the-Loop（MIL）的開發(fā)。在MIL層面，用戶會開發(fā)大量的單元測試用例，在和用戶的討論中發(fā)現，有一種場景比較實用：

提交模型+自動回歸測試+自動報告生成

本文以Git、GitLab、Jenkins為主要工具，介紹如何配置MBD模式下的自動回歸測試+自動報告生成。

詳細配置

注意：通常情況下，Jenkins Server會選擇一個計算能力較強的服務器，本文為了方便選擇將Simulink和Jenkins裝在同一機器上。

1. GitLab的項目創(chuàng)建

先在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命令行操作，優(yōu)勢如下：

Git命令行靈活方便，易于腳本化。

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

Simulink是比較智能的。

一旦你用手動方式做了一遍Git操作，Simulink就自動“記得”哪些文件和Git庫是有關聯(lián)。

3.Jenkins的配置

首先，安裝Jenkins時候裝上必用的幾個plugin ：Git plugin、GitLab plugin、GitLab Hook plugin。然后在Jenkins里面建立項目。

配置源代碼GitLab倉庫設置

配置BuildTrigger

在GitLab的項目的settings -> integrations:

加上webhook后可以測試一下。

然后回到Jenkins的項目設置：

配置編譯腳本：

runMyTests.m 是一個MATLAB腳本，它的功能就是將指定位置的測試用例找到，然后批量執(zhí)行所有回歸測試用例，最后輸出指定格式的報告。

3. 運行

打開模型

瀏覽測試用例：測試用例一共有6個

編輯模型后，提交到GitLab。

在Jenkins上編譯成功，查看編譯和測試報告。

在實際的工程項目中，隨著項目和人員的擴展，越來越多的開發(fā)人員會利用合適的代碼版本管理和持續(xù)集成工具進行并行開發(fā)。Git、GitLab、Jenkins這個組合適用于任意大小規(guī)模的持續(xù)集成開發(fā)模式。持續(xù)集成也是敏捷開發(fā)的一個最佳實踐。而MBD的模式——早期驗證、虛擬集成完全符合敏捷開發(fā)的理念。越來越多的開發(fā)人員在使用MBD的同時也關注如何擁抱敏捷開發(fā)。