이 페이지는 기계 번역되었습니다.
번역 품질에 대한 1분 설문 조사에 참여해 주세요.
Simulink 모델 검증의 지속적 통합
작성자: David Boissy, Paul Urban, Krishna Balasubramanian, Pablo Romero Cumbreras, Colin Branch 및 Jemima Pulipati, MathWorks
R2022a 이상을 사용하고 Simulink Check™ 라이선스가 있는 경우, CI/CD Automation for Simulink Check 지원 패키지를 사용하여 CI 통합을 간소화할 수 있습니다. 지원 패키지를 사용하면 팀을 위한 공정 모델을 정의하고 CI 시스템을 설정하여 CI의 파이프라인으로 공정 내 작업을 자동으로 실행할 수 있습니다. 지원 패키지에는 여러 CI 플랫폼에 대한 지원이 포함되어 있어 프로젝트 및 공정에 맞는 파이프라인을 자동으로 생성할 수 있으므로 수동으로 업데이트할 필요가 없습니다.
주요 특징:
- 내장 작업: 모델 어드바이저로 모델링 표준을 검사하고, Simulink Test™로 테스트를 실행하고, Embedded Coder®로 코드를 생성하는 등의 활동을 위한 내장 작업을 사용해 모델 기반 개발 및 검증 워크플로에서 일반적인 작업을 자동화할 수 있습니다. 개발 및 검증 활동을 위해 다양한 스크립트를 관리하는 대신, 이러한 내장 작업을 재구성하여 사용하면 일관된 실행 및 체계적 작업 결과를 얻을 수 있습니다.
- 증분 빌드: 프로젝트 변경으로 인한 영향을 파악하고 영향을 받은 작업만 자동으로 다시 실행하여 빌드 효율성을 개선할 수 있습니다. Process Advisor 앱과 빌드 시스템은 오래된 결과가 있는 작업을 재실행하고 최신인 작업을 자동으로 건너뛸 수 있습니다.
- 자동 파이프라인 생성: 지원 패키지의 템플릿 파일을 사용하면 파이프라인을 자동으로 생성할 수 있으므로 프로젝트나 공정을 변경할 때 CI/CD 구성 파일을 수동으로 업데이트할 필요가 없습니다. 파이프라인 생성기의 설정을 쉽게 사용자 정의하여 작업을 여러 작업으로 분리하고, 모델 작업을 병렬로 실행하고, 다른 파이프라인 동작을 변경할 수 있습니다.
더 자세한 내용은 지속적 통합 및 Jenkins에 통합 항목을 참조해 주세요.
이 글은 2부작 시리즈 중 첫 번째 글입니다. 1부에서는 버전 컨트롤을 위한 GitLab® 활용과 CI(지속적 통합)을 위한 Jenkins® 활용에 대해 살펴볼 수 있습니다. 2부인 GitLab을 통한 Simulink 모델 검증의 지속적 통합에서는 버전 컨트롤 및 CI를 위해 GitLab을 사용하는 방법에 대해 살펴볼 수 있습니다.
CI(지속적 통합)는 점점 더 인기를 얻고 있으며 모델 기반 설계의 필수적인 부분이 되어 가고 있습니다. 그런데 CI란 무엇일까요? 이 기술의 이점은 무엇이며 어떤 문제를 해결하려고 할까요? Simulink®는 어떻게 CI 생태계에 적용될까요? 여러분의 프로젝트에 CI를 가장 잘 활용하려면 어떻게 해야 할까요?
여러분이 모델 기반 설계에는 익숙하지만 CI에는 익숙하지 않다면 이런 질문을 할 수 있을 것입니다. 이 기술 칼럼에서는 일반적인 CI 워크플로를 살펴보고 이를 모델 기반 설계에 적용할 것입니다. 이후 Jenkins, GitLab 및 Simulink Test를 사용해 해당 워크플로의 예시를 살펴보겠습니다.
이 예제에서 사용된 프로젝트는 다운로드할 수 있습니다.
CI란?
CI는 개발자가 소스 코드 변경 사항을 정기적으로 중앙 리포지토리에 제출하고 병합하는 애자일 방법론의 모범 사례입니다. 이러한 "변경 세트"는 자동으로 빌드되고 검증되며 릴리스됩니다. 그림 1은 개발 워크플로와 함께 이 기본 CI 워크플로를 보여줍니다.
워크플로의 개발 부분에서는 모델과 테스트가 개발, 검증, 병합, 검토되어 개발자 데스크탑의 버전 컨트롤 시스템에 제출됩니다. 그러면 버전 컨트롤 시스템이 워크플로의 자동화된 CI 부분을 트리거합니다. CI 워크플로의 핵심 부분은 다음과 같습니다.
빌드: 소스 코드와 모델은 오브젝트 파일과 실행 파일이 됩니다.
테스트: 테스트는 품질 게이트로 수행됩니다.
패키지: 실행 파일, 문서, 아티팩트 및 기타 인도물은 최종 사용자에게 전달하기 위해 하나로 묶입니다.
배포: 패키지는 프로덕션 환경에 배포됩니다.
이 4단계를 합쳐서 CI "파이프라인"이라고 합니다. 파이프라인은 일반적으로 자동화되며, 시스템에 따라 완료하는 데 몇 분에서 며칠이 걸릴 수 있습니다. 이러한 단계 전반에 걸쳐 부품 목록, 테스트 결과, 리포트 등 다양한 아티팩트가 생성된다는 점에 유의하세요.
CI 워크플로는 종종 버전 컨트롤 시스템과 관련된 개발자 워크플로와 함께 사용됩니다. 이러한 워크플로에서 개발자는 종종 로컬 리포지토리에 변경 사항을 보관하고 로컬 CI 파이프라인을 사용하여 배포 전에 변경 사항을 검증합니다.
CI의 이점은 무엇인가요?
CI를 구현한 팀은 일반적으로 다음과 같은 이점을 보고합니다.
- 반복성. CI 파이프라인은 빌드, 테스트, 패키징, 배포를 위한 일관되고 반복 가능한 자동화 공정을 제공합니다. 반복 가능한 자동화를 통해 개발자는 필요한 작업에 집중하고 프로젝트에 소요되는 시간을 절약할 수 있습니다. 이는 위험 감소의 중요한 측면이기도 하며 종종 인증 요건입니다.
- 품질 보증. 수동 테스트는 효과적이지만, 며칠 전의 스냅샷을 기반으로 하기 때문에 반복성이 부족합니다. CI를 사용하면 변경 사항이 항상 최신 코드 베이스에 대해 테스트됩니다.
- 개발 시간 단축. 품질 보증이 내장된 반복 가능한 공정 덕분에 고품질 제품을 더 빨리 제공할 수 있었습니다. 자동화된 배포는 귀하의 코드가 언제나 프로덕션에 사용될 준비가 되어 있다는 것을 의미합니다.
- 협업 개선. CI를 통해 개발자는 변경 세트를 관리하고 코드를 프로덕션 라인에 병합하기 위한 정의된 공정을 갖게 됩니다. 일관된 공정을 통해 대규모 팀을 관리할 수 있으며, 신규 개발자를 확보하는 데 드는 비용을 줄일 수 있습니다.
- 감사 준비가 된 코드. CI 워크플로는 광범위한 감사용 기록을 제공합니다. CI 파이프라인을 통과하는 모든 변경 사항에 대해 변경을 수행한 사람, 변경을 검토한 사람, 변경의 특성, 종속성, 테스트 및 결과, 그리고 변경 과정에서 생성된 관련 리포트 및 아티팩트를 식별할 수 있습니다.
모델 기반 설계는 CI에 어떻게 적용되는가?
CI 워크플로와 툴은 설계상 언어와 도메인에 구애받지 않습니다. 이는 CI 툴, 시스템 및 공정이 모델 기반 설계를 따를 수 있도록 가르치는 것, 즉 Simulink 및 관련 툴을 CI 워크플로의 공통어로 만드는 작업이 도전 과제라는 의미입니다
이는 모델 기반 설계의 세 가지 핵심 구성 요소인 검증, 코드 생성, 테스트를 CI 워크플로에 통합하여 수행할 수 있습니다(그림 2). 모델 기반 설계는 초기 검증을 강조하며, 이는 빌드 단계 전에 확인 단계가 있는 CI 파이프라인에 매핑됩니다. 코드 생성은 빌드 단계에서 이루어집니다. 테스트 단계에서는 생성된 코드의 시뮬레이션을 통한 동적 테스트와 정적 분석을 수행할 수 있습니다.
다음은 모델 기반 설계를 따르도록 CI 워크플로를 가르치는 과정의 개요입니다.
개발. 개발 활동에는 MATLAB®, Simulink, 코더 및 툴박스 등이 사용됩니다. MATLAB 프로젝트는 작업을 구성하고, 협업하고, 버전 컨트롤 시스템과 상호 작용하는 데 사용됩니다.
테스트. Simulink Check를 사용해 시뮬레이션 및 코드 생성 전에 모델 품질 검사를 수행할 수 있습니다. Simulink Test는 시뮬레이션 기반 테스트를 개발, 관리, 실행하는 데 사용됩니다. Simulink Coverage™는 커버리지를 측정하고 테스트 효과를 평가하는 데 사용됩니다. 품질 검사, 테스트 결과, 적용 범위 측정 항목은 개발자가 자신의 작업을 검증하는 품질 관문으로 사용될 수 있습니다.
병합. MATLAB의 파일 및 폴더 비교 기능은 MATLAB 파일을 비교하고 병합하는 데 사용됩니다. 모델 비교 툴은 Simulink 모델을 비교하고 병합하는 데 사용됩니다.
검토. 검토는 변경 사항을 버전 컨트롤 시스템에 제출하기 전 품질 관리 공정의 마지막 단계입니다. 여기서는 MATLAB 스크립트와 Simulink 모델의 변경 사항을 검토합니다. 사전 자격 심사를 거친 테스트 결과는 제출 전 최종 품질 관문으로 검토됩니다.
제출. MATLAB 프로젝트는 버전 컨트롤 시스템에 대한 인터페이스를 제공합니다.
검증. 로컬 검증에 사용되는 것과 같은 툴인 Simulink Check을 사용해 CI 시스템 내 자동 검증을 수행합니다.
빌드. MATLAB Coder™, Simulink Coder™ 및 Embedder Coder를 사용해 SIL(Software-in-the-Loop) 테스트를 위한 코드를 생성합니다.
테스트. 로컬 테스트에 사용되는 것과 같은 툴인 Simulink Test를 사용해 CI 시스템 내 자동화 테스트를 수행합니다.
패키지 및 배포. 패키징은 실행 파일, 문서, 아티팩트 및 기타 인도물을 묶어 최종 사용자에게 전달하는 것입니다. 배포란 패키지된 소프트웨어를 출시하는 것을 말합니다. 모델 기반 설계의 워크플로에서 이러한 단계는 조직과 그룹마다 매우 다양하며, 종종 다른 팀에 전달할 준비가 된 제품으로 다양한 빌드와 인증 아티팩트를 묶는 작업이 포함됩니다.
최신 개발 툴과 관행을 통해 개발자는 더욱 강력한 시스템을 만들고 기능을 일찍 자주 테스트할 수 있습니다. CI 시스템이 워크플로에 통합되면 단위 수준 테스트와 시스템 수준 테스트가 자동화됩니다. 즉, 개발자는 기능이 올바르게 통합되었는지 확인하는 것이 아니라 새로운 기능을 개발하는 데 집중할 수 있습니다.
다음 사례 연구에서는 CI와 모델 기반 설계를 통합한 워크플로를 설명합니다.
사례 연구: CI 시스템 내에서 검증, 구축 및 테스트된 Simulink 모델
이 예에서는 CI를 기반으로 모델 기반 설계를 사용하여 자동차 차선 추종 시스템에 대한 요구사항 기반 테스트를 수행합니다. (그림 3)
우리가 사용할 파이프라인(그림 4)은 각 Jenkins 빌드에서 실행됩니다.
그림 4. 차선 추종의 예를 보여주는 파이프라인입니다.
파이프라인의 단계는 다음과 같습니다.
- 표준 준수 확인: MATLAB 단위 스크립트는 간단한 모델 어드바이저 검사를 실행합니다. 평가 기준은 모델에 연결되지 않은 선이 없음을 보장합니다.
- 모델 구축: MATLAB 단위 테스트 파일은 모델에 대한 프로덕션 SIL 코드를 빌드합니다. 빌드가 경고 없이 성공하면 평가 기준은 통과된 것입니다.
- 테스트 케이스 실행: Simulink Test의 테스트 스위트는 여러 가지 주행 시나리오를 사용하여 차선 추종 제어기를 테스트합니다. 제어기의 만족스러운 작동을 확인하기 위해 세 가지 평가 기준이 사용됩니다.
- 충돌 회피: 주행 시나리오 중 어느 시점에서도 자차량과 충돌하지 않습니다.
- 안전 거리 유지: 선행 차량과 자차량 사이의 시간 간격이 1.5초 이상입니다. 두 차량 사이의 시간 간격은 계산된 주행 간격과 자차량 속도의 비율로 정의됩니다.
- 차선 추종: 차선 중심선으로부터 횡방향 편차는 0.2m 이내입니다.
- 패키지 아티팩트: 이전 단계에서는 각각 모델 어드바이저 리포트, 생성된 실행 파일, 나중에 사용하거나 참조할 수 있는 테스트 결과 세트를 비롯한 아티팩트가 생성됩니다.
워크플로 단계
워크플로는 다음 단계로 구성됩니다(그림 5):
- Jenkins에서 빌드 트리거 및 검증 및 빌드 단계가 통과되는지 확인합니다.
- Jenkins에서 테스트 케이스 실패를 감지합니다.
- 데스크탑 MATLAB에서 문제를 재현합니다.
- 모델에서 평가 기준을 완화하여 문제를 해결합니다.
- 테스트 케이스가 통과되도록 로컬에서 테스트합니다.
- 테스트 브랜치에서 변경 사항을 병합 및 검토합니다.
- Git™에 변경 사항을 커밋하고 Jenkins에서 빌드를 트리거합니다.
- Jenkins에서 확인, 빌드 및 테스트합니다.
CI 루프를 처음 통과하는 데 실패한 모습이 왼쪽 상단에 표시되어 있습니다. CI 테스트 실패, 로컬 재생산, 기준 완화 및 CI 워크플로의 성공적인 완료를 보여줍니다.
워크플로 세부 정보
- 우리는 Jenkins에서 Build Now를 선택해 빌드를 트리거하는 것으로 시작합니다. Simulink Check는 코드 생성 패스를 검사합니다.

- 다음으로, 우리는 두 번째 검증 단계에서 테스트 케이스 실패를 감지합니다. 테스트 스위트
LaneFollowingTestScenarios
의 테스트 케이스LFACC_Curve_CutInOut_TooClose
는 평가 기준에 실패합니다.

- 실패를 더 잘 이해하기 위해 우리는 Simulink Test를 사용해 로컬에서 실패를 재현합니다. 테스트 파일
LaneFollowingTestScenarios.mldatx
를 열고 테스트 케이스LFACC_Curve_CutInOut_TooClose
를 실행합니다. 안전 거리 평가 기준에 부합하지 않는다는 점에 유의하세요. 선행 차량과 자차량 간의 시간 간격을 설정하는 데 더 많은 유연성이 필요합니다.

- 우리는 문제를 이해하게 되었으니 이제 문제를 해결할 것입니다.
LaneFollowingTestBenchExample.slx
모델을 열어 Collision Detection/Test Assessments Test Sequence 블록으로 이동합니다. 첫 번째 평가에서는 선행 차량과 자차량 사이의 시간 간격이 한 번에 2초 이상 1.5초 이하로 떨어져서는 안 된다고 주장합니다.
GlobalAssessments % Ensure that the time gap between the ego vehicle and lead vehicle does not dip below % 1.5s for more than 2s at a time. verify(duration(time_gap < 1.5, sec) < 2); % Verify that no collision was detected verify(~collision); % Verify that the absolute value of lateral deviation from the lane centerline does not exceed 0.2m % for more than 5s at a time. verify(duration(abs(lateral_deviation) > 0.2, sec) < 5);
이러한 평가는 테스트되고 있는 과격한 운전 조작에 비해 너무 제한적입니다. 이 예시의 목적상, 시간 간격이 한 번에 5초 이상 0.8초 미만으로 떨어지지 않도록 평가 기준을 완화합니다.
GlobalAssessments % Ensure that the time gap between the ego vehicle and lead vehicle does not dip below % 0.8s for more than 5s at a time. verify(duration(time_gap < 0.8, sec) < 5); % Verify that no collision was detected verify(~collision); % Verify that the absolute value of lateral deviation from the lane centerline does not exceed 0.2m % for more than 5s at a time. verify(duration(abs(lateral_deviation) > 0.2, sec) < 5);
- 시뮬레이션상에서는 문제가 해결된 것으로 보입니다. 이를 확인하기 위해, 우리는로컬로 테스트하여 모델을 저장하고 Test Manager에서 테스트를 재실행합니다. 새로운 평가 기준에 통과한 것을 주목하세요.

- 우리는 해당 문제를 해결하고 현지에서 검증했습니다. 이제 우리는 모델 비교 툴을 사용해 버전 컨트롤에 커밋하기 전에 변경 사항을 검토합니다.

모델 비교 툴의 퍼블리시 기능을 사용하여 코드를 검토할 수도 있습니다.

- 버그가 수정되었으므로 변경 사항을 MATLAB 프로젝트와 함께 GitLab에 밀어 넣고, 평가 기준의 변경 사항을 알리는 커밋 메시지를 추가합니다.
그런 다음 GitLab에서 최신 커밋을 확인합니다.
GitLab은 자동으로 Jenkins에서 빌드를 트리거합니다. Jenkins 프로젝트 대시보드는 빌드 상태와 진행 상황을 보여줍니다.

- Jenkins 빌드가 실행됩니다. 검증, 빌드 및 테스트 파이프라인 단계가 이제 끝난 것을 볼 수 있습니다.
이제 테스트 브랜치의 변경 사항을 메인 브랜치에 병합하기 위한 병합 요청을 시작할 수 있습니다. GitLab에서 Repository 아래, Branches를 선택하고 테스트 브랜치의 최신 커밋 옆의 Merge request를 클릭합니다.
양식을 작성하고 병합 요청을 제출합니다.
브랜치 소유자로서 우리는 Merge 버튼을 클릭해 병합 요청을 수락할 수 있습니다. 모든 변경 사항은 이제 메인 브랜치에 반영됩니다.

예제 사용: 툴, 리소스 및 요구사항
다음 섹션에서는 시작하는 데 도움이 되는 리소스, 필요한 툴 및 툴 구성 방법을 설명합니다.
시스템 구성
CI 시스템으로는 Jenkins를 활용하고 버전 컨트롤 시스템으로는 GitLab을 활용합니다. MATLAB, Jenkins, GitLab은 함께 작동하도록 구성되어야 합니다. 다음 튜토리얼은 설정에 도움이 될 것입니다.
튜토리얼은 GitLab과 Jenkins에 특화되어 있지만, 개념은 다른 버전 컨트롤 및 CI 시스템에도 적용할 수 있습니다.
필요한 툴
이 예제에는 다음과 같은 툴이 필요합니다.
- Jenkins 설치 버전 2.7.3 이상. Jenkins는 지속적 통합에 사용됩니다.
- MATLAB Plugin for Jenkins 버전 1.0.3 이상. MATLAB, Simulink 및 Simulink Test 모두 이 플러그인을 활용하여 Jenkins와 통신합니다. GitHub에서 자세히 알아보세요.
- 필요한 추가 플러그인:
- GitLab 계정. GitLab은 소스 컨트롤에 사용되며 클라우드 서비스로 제공됩니다. MATLAB 프로젝트에는 GitLab과 통신하기 위한 Git 인터페이스가 포함되어 있습니다.
CI에 대한 라이선스 고려 사항
여러 호스트 또는 클라우드에서 CI를 수행할 계획이라면 continuous-integration@mathworks.com에 문의해 도움을 요청하세요. 참고: MATLAB 및 Simulink Coder 및 Compiler 제품과 같은 변환 제품은 CAL(Client Access License)이 필요할 수 있습니다.
부록: MATLAB, GitLab 및 Jenkins 구성
1단계. 소스 컨트롤을 사용하도록 MATLAB 프로젝트 구성
우리 예제의 첫 번째 단계는 GitLab으로 소스 컨트롤을 사용하도록 프로젝트를 구성하는 것입니다.
MBDExampleWithGitAndJenkins
라는 이름의 새 디렉토리를 만들고, 여기에 예제를 불러온 후, MATLAB프로젝트 MBDExampleWithGitAndJenkins.prj
를 엽니다.- GitLab에서 원격 리포지토리가 될 새로운 프로젝트를 만듭니다.
MBDExampleWithGitAndJenkins
로 이름을 지정하고 호스트되고 있는 URL을 기록합니다. - MATLAB에서 소스 컨트롤을 사용하도록 프로젝트를 변환합니다. 프로젝트 탭에서 소스 컨트롤 사용을 클릭합니다.

소스 컨트롤에 프로젝트 추가를 클릭합니다.

- 변환을 클릭합니다.

- 완료되면 프로젝트 열기를 클릭합니다.

이 프로젝트는 이제 로컬 Git 소스 컨트롤에 속합니다.
2단계. 변경 사항 커밋 및 로컬 리포지토리를 GitLab에 밀어넣기
- 프로젝트 탭에서 원격을 클릭합니다.

- GitLab의 원격 저장소의 URL을 지정합니다.

유효성 검사를 클릭해 원격 리포지토리에 대한 연결이 성공적인지 확인하고 확인을 클릭합니다. 이제 이 프로젝트는 GitLab을 사용하여 변경 사항을 밀어 넣고 끌어오도록 구성되었습니다.
- 커밋을 클릭해 초기 커밋을 수행합니다.


- 밀어넣기를 클릭해 로컬 리포지토리의 모든 변경 사항을 원격 GitLab 리포지토리로 밀어 넣습니다.

- GitLab 대시보드를 새로 고치고 MATLAB 프로젝트의 내용을 살펴보세요.
3단계: 테스트 브랜치 생성
이 단계에서는 메인 브랜치와 병합하기 전에 변경 사항을 테스트하고 확인하기 위한 테스트 브랜치를 만듭니다.
- 브랜치를 클릭합니다.

- 확장브랜치와 태그 생성 섹션을 확장하고, 브랜치 이름을 "Test"로 지정하고, 만들기를 클릭합니다.
- 브랜치 브라우저에서 Test를 관찰합니다. Test 브랜치에서 전환 그리고 닫기를 클릭합니다.
- MATLAB에서 밀어넣기를 선택하여 변경 사항을 GitLab으로 밀어 넣고 GitLab의 Test 브랜치를 관찰합니다.
4단계. MATLAB을 호출하도록 Jenkins 구성
- 필수 플러그인 두 개를 설치하세요:
- GitLab 플러그인 — 이 플러그인을 사용하면 GitLab에서 Jenkins 빌드를 트리거하고 GitLab UI에 결과를 표시할 수 있습니다.
- MATLAB 플러그인 — 이 플러그인은 MATLAB 및 Jenkins를 통합하고 MATLAB 및 Simulink를 호출하기 위한 Jenkins 인터페이스를 제공합니다.
- New Item을 선택하고,
MBDExampleUsingGitAndJenkins
라는 이름의 새로운 FreeStyle 프로젝트를 생성합니다. - Source Code Management에서 Git을 활성화하고 Jenkins를 GitLab 리포지토리로 지정한 후 테스트 브랜치를 입력하여 빌드합니다. 참고: 로그인 또는 비밀번호 및 GitLab API 토큰이 필요합니다.
- GitLab의 테스트 브랜치에 밀어넣기 요청이 있을 때 빌드를 실행하도록 빌드 트리거를 구성합니다. Build Triggers 섹션에서 Advanced > secret token을 선택합니다. 이 토큰은 GitLab에서 빌드를 요청하고 Jenkins에 인증하는 데 사용됩니다. 비밀 토큰과 GitLab 웹훅을 기록해 보세요.
- 빌드 환경을 구성합니다. Use MATLAB version을 선택하고 MATLAB 루트를 입력합니다.
- 빌드 단계를 구성합니다.
Add build step을 클릭하고 Run MATLAB Command를 선택합니다. 명령 openProject('SltestLaneFollowingExample.prj');
를
LaneFollowingExecModelAdvisor
입력해 프로젝트를 열고 모델 어드바이저 검사를 실행합니다.
Add build step을 클릭하고 Run MATLAB Command를 선택합니다. 다음 명령을 입력합니다: openProject('SltestLaneFollowingExample.prj');
LaneFollowingExecControllerBuild.
Add build step을 클릭하고 Run MATLAB Tests를 선택합니다. TAP test results 및 Cobertura code coverage를 선택해 빌드 구성을 완료합니다.
이 작업은 TAP Extended Test Results가 선택되었을 때 TAP 테스트 결과를 구문 분석하고 볼 수 있도록 합니다. 출력에는 실행된 테스트 케이스의 개요, 결과 요약 및 MATLAB 콘솔의 로그가 포함됩니다.

TAP 플러그인은 또한 최신 테스트 실행 결과를 수집하여 아래에 표시된 것과 같이 상태 다이어그램을 표시합니다. 다이어그램을 클릭하면 이전 빌드에 접근할 수 있습니다.

6단계. HTML 리포트 퍼블리시
Add post-build action > Publish HTML reports를 클릭합니다. HTML 리포트가 퍼블리시될 상대 루트 경로와 해당 경로에 있는 인덱스 페이지의 파일 이름을 입력합니다.
퍼블리시할 HTML 리포트의 개수만큼 항목을 추가합니다. 이 시나리오에서는 두 개의 웹 리포트가 있습니다. 모델 어드바이저 요약 및 코드 생성 리포트. 이는 MATLAB 내장 함수를 사용하여 작성된 표준 리포트입니다. 사용자 정의 HTML 리포트를 추가할 수 있습니다.
Jenkins 작업 페이지에서 모든 HTML 리포트에 대한 마지막 빌드에 해당하는 리포트 링크를 찾을 수 있습니다. Publishing options 아래의 “Always link to last build” 체크박스를 활성화하면, 이 플러그인은 빌드 상태에 관계없이 마지막 빌드에 대한 리포트를 퍼블리시합니다. 이 체크박스가 활성화되어 있지 않으면 플러그인은 마지막 "성공적인" 빌드에만 링크합니다.
7단계. Jenkins에서 빌드를 트리거하기 위한 GitLab 구성
메인 브랜치에 새로운 밀어넣기가 발생하면 Jenkins에서 자동 빌드를 트리거하도록 GitLab을 구성합니다. 이를 하려면 Settings > Webhooks로 이동합니다. Build Trigger 구성에서 Jenkins에서 제공된 웹훅 URL과 비밀 토큰을 사용하고 Push events를 선택합니다.
참고: GitLab이 Jenkins 설치를 찾을 수 있도록 localhost 대신 URL 섹션에 전체 주소 도메인 이름을 사용하세요.

Test 풀다운에서 Push Events를 선택해 통합을 테스트합니다. GitLab에서 "Hook executed successfully: HTTP 200"라는 메시지가 표시됩니다. Jenkins가 빌드를 시작합니다.

8단계. Jenkins-to-GitLab 인증 구성
GitLab에 Jenkins 빌드 상태를 자동으로 퍼블리시하려면 Jenkins-GitLab 인증을 구성해야 합니다.
- API 범위를 선택하여 GitLab에서 개인 액세스 토큰을 생성합니다.

- 토큰을 복사하고 Jenkins Configure System에서 GitLab 연결을 생성합니다.
참고: 연결은 여러 Jenkins 작업에 걸쳐 재사용될 수 있으며 사용자에게 최소한 “maintainer” 권한이 있는 경우 전역적으로 구성될 수 있습니다.
9단계. GitLab 파이프라인에 Jenkins 통합
Jenkins를 GitLab 파이프라인에 통합하려면 Jenkins에서 GitLab 연결을 구성하고 작업 상태를 GitLab에 퍼블리시해야 합니다.
- Jenkins 작업의 General 섹션에서 GitLab Connection을 선택하세요.
- GitLab에 빌드 상태를 퍼블리시하는 빌드 후 작업을 추가합니다.
참고: 이 작업에는 파라미터가 없으며 기존 GitLab 연결을 사용하여 GitLab에 빌드 상태를 퍼블리시하고 모든 커밋 및 병합 요청에 대한 양방향 추적 기능을 생성합니다.

10단계. 요구사항 기반 테스트 메트릭 시각화 (R2020b)
요구사항 기반 테스트 메트릭을 통해 요구사항 기반 테스트 활동의 상태와 품질을 평가할 수 있습니다. Model Testing Dashboard를 사용하여 메트릭 결과를 시각화할 수 있습니다.
- 아래에 표시된 함수를 기반으로
collectModelTestingResults.m
이라는 파일을 만듭니다. 이 기능은 메트릭 엔진 인프라를 초기화하고 사용 가능한 모든 모델 메트릭을 수집합니다.
function collectModelTestingResults() % metric capability added in R2020a if exist('metric') metricIDs = [... "ConditionCoverageBreakdown" "CoverageDataService"... "DecisionCoverageBreakdown" "ExecutionCoverageBreakdown"... "MCDCCoverageBreakdown" "OverallConditionCoverage"... "OverallDecisionCoverage" "OverallExecutionCoverage"... "OverallMCDCCoverage" "RequirementWithTestCase"... "RequirementWithTestCaseDistribution" "RequirementWithTestCasePercentage"... "RequirementsPerTestCase" "RequirementsPerTestCaseDistribution"... "TestCaseStatus" "TestCaseStatusDistribution"... "TestCaseStatusPercentage" "TestCaseTag"... "TestCaseTagDistribution" "TestCaseType"... "TestCaseTypeDistribution" "TestCaseWithRequirement"... "TestCaseWithRequirementDistribution" "TestCaseWithRequirementPercentage"... "TestCasesPerRequirement" "TestCasesPerRequirementDistribution"... ]; % collect all metrics for initial reconcile E = metric.Engine(); execute(E, metricIDs); end end
- 이 파일을 프로젝트와 경로에 추가합니다.
new collectModelTestingResults function
을 두 번 호출해 Jenkins에서 메트릭 결과를 수집하도록 구성합니다. 첫 번째 호출은 Simulink Test Manager와의 메트릭 통합을 초기화합니다. 두 번째는 Simulink Test Manager에서 내보낸 결과를 사용하여 메트릭 결과를 수집합니다.- Add build step을 클릭하고 Run MATLAB Command를 다시 선택합니다. 다음 명령을 입력하세요:
openProject('SltestLaneFollowingExample.prj'); collectModelTestingResults
이 빌드 단계를 Run MATLAB Tests 빌드 단계 전으로 배치합니다. - Add build step을 클릭하고 Run MATLAB Command를 다시 선택합니다. 명령을 다시 입력합니다:
openProject('SltestLaneFollowingExample.prj'); collectModelTestingResults
이 빌드 단계를 Run MATLAB Tests 빌드 단계 후로 배치합니다.
- Add build step을 클릭하고 Run MATLAB Command를 다시 선택합니다. 다음 명령을 입력하세요:
- Run MATLAB Tests 빌드 단계에서 Simulink Test Manager results를 선택합니다.

- 파생된 디렉토리에 메트릭 결과를 보관합니다. 내보낸 테스트 관리자 결과도 보관해야 합니다. 이렇게 하면 MATLAB 로 다시 불러올 때 메트릭 결과를 전체적으로 탐색할 수 있습니다.
Add post-build action을 클릭하고 Archive the artifacts를 선택합니다. 경로 derived/**,matlabTestArtifacts/*.mldatx
를 입력해 해당 디렉토리에 저장된 모든 파일을 보관합니다.
참고: 테스트 컴퓨터 외의 다른 컴퓨터에서 MATLAB 내에서 이런 결과를 보려면 다음 작업을 수행하세요.
- 보관된 아티팩트(파생 디렉토리 및 테스트 결과 MLDATX 파일)를 다운로드합니다.
- CI 작업을 실행하는 데 사용된 동일한 버전의 프로젝트를 추출하여 로컬 복사본에 복사합니다.
- MATLAB에서 프로젝트를 열고 Model Testing Dashboard를 시작합니다.
CI에서 생성된 결과는 대시보드에 표시될 것입니다.
Jenkins®는 LF Charities Inc.의 등록 상표입니다.
2024년 기고