В этом примере показано, как использовать панель мониторинга Metrics с инструментами с открытым исходным кодом GitLab™ а также Jenkins™ для тестирования и уточнения модели в непрерывном рабочем процессе интеграционных систем. Непрерывная интеграция - это практика объединения всех рабочих копий файлов проекта разработчика на общую магистраль. Этот рабочий процесс экономит время и повышает качество, поддерживая контроль версий, автоматизируя и стандартизируя тестирование.
Этот пример относится к проекту, содержащему поставляемый проект matlab:sldemo_slproject_airframe и следующие файлы, которые необходимо предоставить:
Сценарий MATLAB, определяющий пороговые значения метрик и настраивающий панель мониторинга метрик.
Единичный тест MATLAB, который собирает метрические данные и проверяет наличие нарушений метрических пороговых значений.
В этом примере сервер непрерывной интеграции Дженкинса используется для выполнения модульного теста MATLAB для определения наличия нарушений метрических пороговых значений. Дженкинс архивирует результаты тестов для загрузки и локального исследования. GitLab - это онлайн-менеджер репозитория Git, который можно настроить для работы с Дженкинсом. На этой диаграмме показано, как Simulink Check, GitLab и Jenkins работают вместе в непрерывном процессе интеграции.
В дополнение к файлам в matlab:sldemo_slproject_airframe проекте необходимо предоставить следующие дополнительные файлы:
Единичный тест MATLAB, который собирает метрические данные для проекта и проверяет, что файлы модели не содержат нарушений метрических пороговых значений. Дополнительные сведения о тестах единиц MATLAB см. в разделе Тесты единиц на основе сценариев.
Сценарий MATLAB, определяющий пороговые значения метрик и настраивающий панель мониторинга метрик. Дополнительные сведения о настройке панели мониторинга показателей см. в разделе Настройка компоновки и функциональности панели мониторинга показателей.
A setup.m файл, активирующий XML-файлы конфигурации, определяющие пороговые значения метрик, устанавливающие пользовательские семейства метрик и настраивающие компоновку панели мониторинга метрик. Для этого примера: setup.m сценарий содержит следующий код:
function setup
% refresh Model Advisor customizations
Advisor.Manager.refresh_customizations();
% set metric configuration with thresholds
configFile = fullfile(pwd, 'config', 'MyConfiguration.xml');
slmetric.config.setActiveConfiguration(configFile);
uiconf = fullfile(pwd, 'config', 'MyDashboardConfiguration.xml');
slmetric.dashboard.setActiveConfiguration(uiconf);
end
setup.m файл. Один sl_customization.m файл, активирующий файл конфигурации Model Advisor для настройки проверок Model Advisor. Дополнительные сведения о создании собственной конфигурации Model Advisor см. в разделе Настройка показателей соответствия.
A run сценарий, который выполняется во время построения Дженкинса. Для этого примера этот код находится в run.m файл:
% script executed during Jenkins build
function run(IN_CI)
if (IN_CI)
jenkins_workspace = getenv('WORKSPACE');
cd(jenkins_workspace);
end
% open the sl project
slproj = simulinkproject(pwd);
% execute tests
runUnitTest();
slproj.close();
if IN_CI
exit
end
end
A cleanup.m файл, восстанавливающий конфигурацию активной метрики в конфигурацию по умолчанию. Для этого примера этот код находится в cleanup.m сценарий файла:
function cleanup
rmpath(fullfile(pwd, 'data'));
Advisor.Manager.refresh_customizations();
% reset active metric configuration to default
slmetric.config.setActiveConfiguration('');
slmetric.dashboard.setActiveConfiguration('');
end
cleanup.m файл.A .gitignore файл, проверяющий, что производные артефакты не возвращены в GitLab. Этот код находится в .gitignore файл:
work/** reports/** *.asv *.autosave
Создайте проект GitLab для управления исходным кодом проекта. Дополнительные сведения см. в разделе https://docs.gitlab.com/ee/README.html.
Установите клиент Git.
Настройка рабочего процесса ветвления. С помощью GitLab из основной ветви создайте временную ветвь для реализации изменений в файлах модели. Инженеры по интеграции могут использовать результаты теста Дженкинса для принятия решения о необходимости объединения временной ветви в главную ветвь. Дополнительные сведения см. в разделе
https://git-scm.com/book/en/v1/Git-Branching-Branching-Workflows.
В разделе Параметры > Репозиторий защитите главную ветвь, принудительно используя запросы на слияние, когда разработчики хотят объединить свои изменения в главную ветвь.
В разделе Настройки на странице Интеграции добавьте Webhook к URL-адресу проекта Дженкинса. Этот webhook запускает задание сборки на сервере Дженкинса.
Установите подключаемые модули GitLab и Tap. Единичный тест MATLAB использует TAPPlugin для потоковой передачи результатов в .tap файл. Чтобы включить передачу статуса теста из MATLAB в задание Дженкинса, Дженкинс импортирует .tap файл.
Создайте проект Дженкинса. Укажите следующие конфигурации:
В проекте Дженкинса нажмите кнопку Настроить.
На вкладке «Общие» укажите имя проекта.
На вкладке Управление исходным кодом в поле URL репозитория укажите URL репозитория GitLab.
На вкладке Триггеры построения (Build Triggers) выберите команду Построить (Build), когда изменение будет перенесено в GitLab.
На вкладке Сборка выполните команду MATLAB для вызова сценария выполнения. Сценарий запуска открывает проект и запускает все модульные тесты. Для проекта в этом примере используется следующий код:
matlab -nodisplay -r... "cd /var/lib/jenkins/workspace/'18b Metrics CI Demo'; run(true)"
На вкладке Действия после сборки настройте подключаемый модуль TAP для публикации результатов TAP Дженкинсу. В поле Test Results укажите reports/*.tap. Чтобы архивировать файлы, укажите reports/**,work/**.
Подключаемый модуль TAP показывает подробные данные теста MATLAB Unit в расширенных результатах задания. Инфраструктура архивирования Дженкинса сохраняет производные артефакты, которые генерируются во время построения Дженкинса.
После настройки проекта, Jenkins и GitLab следуйте непрерывному процессу интеграции.
Создайте локальный клон репозитория GitLab. См. раздел Извлечение файлов из репозитория Git.
В Simulink перейдите в локальный репозиторий GitLab.
Создайте отделение особенности и файлы контроля и усилие. См. разделы Ответвление и объединение файлов с Git и Извлечение, Передача и Выборка файлов с Git.
Внесите необходимые изменения в файлы проекта.
Смоделировать модель и проверить выходные данные в инспекторе данных моделирования.
Выполните модульные тесты MATLAB. Дополнительные сведения см. в разделе runtests.
Добавьте и зафиксируйте измененные модели в ветви элемента. См. разделы Ответвление и объединение файлов с Git и Извлечение, Передача и Выборка файлов с Git.
Передача изменений в репозиторий GitLab. См. разделы Ответвление и объединение файлов с Git и Извлечение, Передача и Выборка файлов с Git.
В GitLab создайте запрос на слияние. Выберите ветвь элемента как исходную ветвь, а целевую ветвь как главную. Щелкните Сравнить ветви (Compare Branches) и Продолжить (Continue).
Если функция реализована не полностью, отметьте запрос на слияние как выполняемую работу, добавив буквы WIP: в начале запроса. Если запрос слияния не помечен как НЗП:, он немедленно запускает построение после создания.
Щелкните Отправить запрос на слияние.
Если буквы WIP: не находятся в начале запроса слияния, команда push запускает построение Дженкинса. В части «Настройка Дженкинса» этого примера вы настроили Дженкинса на выполнение сборки при вставке изменений в GitLab. Чтобы удалить буквы, щелкните Разрешить состояние НЗП.
Перейдите к проекту Дженкинса. В журнале сборки можно просмотреть состояние сборки.
Щелкните Построение (Build).
Нажмите Коснитесь Результаты тестирования.
Для этого примера: MetricThresholdGateway.m единичный тест не прошел для трех метрик, поскольку эти метрики не соответствовали пороговым значениям. Чтобы исследовать эти данные, необходимо загрузить их локально.
Загрузите заархивированные результаты в локальную рабочую область репозитория Git.
Распакуйте загруженные файлы. Копировать reports/ и work/ в соответствующие папки локального репозитория.
Чтобы ознакомиться с результатами, откройте проект и панель мониторинга показателей.
Чтобы устранить ошибки теста, внесите необходимые обновления в модели. Переместите изменения в ветвь элемента в GitLab.
Инженеры по интеграции могут использовать результаты теста Дженкинса для принятия решения о допустимости объединения временной ветви в главную ветвь.
slmetric.config.setActiveConfiguration | slmetric.dashboard.setActiveConfiguration