В этом примере показано, как использовать Метрическую Инструментальную панель с инструментами GitLab™ и Jenkins™ с открытым исходным кодом, чтобы протестировать и совершенствовать вашу модель в непрерывном системном рабочем процессе интегрирования. Непрерывное интегрирование является практикой слияния всего разработчика рабочие копии файлов проекта к разделяемой магистрали. Этот рабочий процесс экономит время и улучшает качество путем поддержания системы контроля версий и автоматизации и стандартизации тестирования.
Этот пример обращается к проекту, который содержит поставленный проект matlab:sldemo_slproject_airframe и эти файлы, которые необходимо обеспечить:
Скрипт MATLAB, который задает метрические пороги и настраивает Метрическую Инструментальную панель.
Модульный тест MATLAB, который собирает метрические данные и проверяет, существуют ли метрические пороговые нарушения.
Этот пример использует Дженкинса непрерывный сервер интеграции, чтобы запустить модульный тест MATLAB, чтобы определить, существуют ли метрические пороговые нарушения. Дженкинс архивирует результаты испытаний для вас загрузить и заняться расследованиями локально. GitLab является онлайновым менеджером по репозиторию Git, которого можно сконфигурировать, чтобы работать с Дженкинсом. Эта схема показывает, как Simulink Check, GitLab и Дженкинс работают совместно в непрерывном рабочем процессе интегрирования.
В дополнение к файлам в matlab:sldemo_slproject_airframe проекте необходимо обеспечить эти дополнительные файлы:
Модульный тест MATLAB, который собирает метрические данные для проекта и проверяет, что файлы модели не содержат метрических пороговых нарушений. Для получения дополнительной информации о Модульных тестах MATLAB смотрите Модульные тесты На основе скриптов.
Скрипт MATLAB, который задает метрические пороги и настраивает Метрическую Инструментальную панель. Для получения дополнительной информации о том, как настроить Метрическую Инструментальную панель, смотрите, Настраивают Метрическое Размещение Инструментальной панели и Функциональность.
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 смотрите, Конфигурируют Метрики Податливости.
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
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 файл..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.
Под Settings> Repository, защитите основную ветвь путем осуществления использования запросов слияния, когда разработчики захотят объединить свои изменения в основную ветвь.
Под Settings, на странице Integrations, добавляет webhook к URL вашего проекта Дженкинса. Этот webhook инициировал задание сборки на сервере Дженкинса.
Установите плагины GitLab и Касания. Модульный тест MATLAB использует TAPPlugin, чтобы передать результаты потоком к .tap файл. Чтобы включить коммуникацию тестового состояния от MATLAB до задания Дженкинса, Дженкинс импортирует .tap файл.
Создайте проект Дженкинса. Задайте эти настройки:
В вашем проекте Дженкинса нажмите Configure.
На вкладке General задайте название проекта.
На вкладке Source Code Management, для поля Repository URL, задают URL вашего репозитория GitLab.
На вкладке Build Triggers выберите Build when a change is pushed to GitLab.
На вкладке Build выполните MATLAB, чтобы вызвать скрипт запуска. Скрипт запуска открывает проект и запускает все модульные тесты. Для проекта в этом примере код:
matlab -nodisplay -r... "cd /var/lib/jenkins/workspace/'18b Metrics CI Demo'; run(true)"
Во вкладке Post-build Actions сконфигурируйте плагин TAP, чтобы опубликовать результаты TAP Дженкинсу. В поле Test Results задайте reports/*.tap. Для Files to archive задайте reports/**,work/**.
Плагин TAP показывает детали от Модульного теста MATLAB в расширенных результатах задания. Инфраструктура архивирования Дженкинса сохраняет выведенные артефакты, которые сгенерированы во время сборки Дженкинса.
После подготовки вашего проекта Дженкинс и GitLab, следуют за непрерывным рабочим процессом интегрирования.
Создайте локальный клон репозитория GitLab. Смотрите Получают Файлы из Git-репозитория.
В Simulink перейдите к локальному репозиторию GitLab.
Создайте ветвь функции и файлы контроля и выборку. Смотрите Файлы Ветви и Слияния с Git и Получением по запросу, Нажатием и Файлами Выборки с Git.
Внесите любые необходимые изменения в файлы проекта.
Симулируйте модель и подтвердите выход в Инспекторе Данных моделирования.
Запустите модульные тесты MATLAB. Для получения дополнительной информации смотрите runtests.
Добавьте и передайте модифицированные модели ветви функции. Смотрите Файлы Ветви и Слияния с Git и Получением по запросу, Нажатием и Файлами Выборки с Git.
Продвиньте изменения в репозитории GitLab. Смотрите Файлы Ветви и Слияния с Git и Получением по запросу, Нажатием и Файлами Выборки с Git.
В GitLab создайте запрос слияния. Выберите ветвь функции как исходную ветвь и целевую ветвь как ведущее устройство. Нажмите Compare Branches and Continue.
Если опция не полностью реализована, отметьте запрос слияния как происходящая работа путем добавления букв WIP: в начале запроса. Если запрос слияния не отмечен WIP: это сразу инициировало сборку после создания.
Нажмите Submit Merge Request.
Если буквы WIP: не в начале запроса слияния, команда нажатия инициировала сборку Дженкинса. В части Setup Дженкинса этого примера вы сконфигурировали Дженкинса, чтобы выполнить сборку, когда вы продвинули изменения в GitLab. Чтобы удалить буквы, нажмите Resolve WIP status.
Перейдите к проекту Дженкинса. В Истории Сборки вы видите состояние сборки.
Кликните по сборке.
Нажмите Tap Test Results.
В данном примере MetricThresholdGateway.m модульный тест не передал для трех метрик, потому что эти метрики не соответствовали порогам. Чтобы исследовать эти данные, необходимо загрузить данные локально.
Загрузите заархивированные результаты на локальную рабочую область репозитория Git.
Разархивируйте загруженные файлы. Скопируйте reports/ и work/ папки к соответствующим папкам в локальном репозитории.
Чтобы исследовать результаты, откройте проект и Метрическую Инструментальную панель.
Чтобы разрешить непройденные тесты, сделайте необходимые обновления моделей. Продвиньте изменения в ветви функции в GitLab.
Инженеры интегрирования могут использовать результаты испытаний Дженкинса решить, когда приемлемо выполнить слияние временной ветви в основную ветвь.
slmetric.config.setActiveConfiguration | slmetric.dashboard.setActiveConfiguration