Зафиксируйте метрические пороговые нарушения в непрерывном системном рабочем процессе интегрирования

Этот пример использует:

В этом примере показано, как использовать Метрическую Инструментальную панель с инструментами GitLab™ и Jenkins™ с открытым исходным кодом, чтобы протестировать и совершенствовать вашу модель в непрерывном системном рабочем процессе интегрирования. Непрерывное интегрирование является практикой слияния всего разработчика рабочие копии файлов проекта к разделяемой магистрали. Этот рабочий процесс экономит время и улучшает качество путем поддержания системы контроля версий и автоматизации и стандартизации тестирования.

Этот пример обращается к проекту, который содержит поставленный проект matlab:sldemo_slproject_airframe и эти дополнительные файлы, которые относятся к этому примеру:

  • Скрипт MATLAB, который задает метрические пороги и настраивает Метрическую Инструментальную панель.

  • Модульный тест MATLAB, который собирает метрические данные и проверяет, существуют ли метрические пороговые нарушения.

Пример использует Дженкинса непрерывный сервер интеграции, чтобы запустить модульный тест MATLAB, чтобы определить, существуют ли метрические пороговые нарушения. Дженкинс архивирует результаты испытаний для вас загрузить и заняться расследованиями локально. GitLab является онлайновым менеджером по репозиторию Git, которого можно сконфигурировать, чтобы работать с Дженкинсом. Эта схема показывает, как Simulink Check, GitLab и Дженкинс работают совместно в непрерывном рабочем процессе интегрирования.

Настройка проекта

Проект содержит всю модель, данные и конфигурационные файлы включая эти файлы, которые требуются для этого примера:

  • Модульный тест 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
    На вкладке Project нажмите Startup Shudown. Для поля Startup files задайте setup.m файл.

    Для получения дополнительной информации о том, как настроить Метрическую Инструментальную панель, смотрите, Настраивают Метрическое Размещение Инструментальной панели и Функциональность.

  • sl_customization.m файл, который активирует конфигурационный файл 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
    На вкладке Project нажмите Startup Shudown. Для поля Shutdown files задайте cleanup.m файл.

  • .gitignore файл, который проверяет, что в выведенных артефактах не зарегистрировались GitLab. Этот код находится в .gitignore файл:

    work/**
reports/**
*.asv
*.autosave

GitLab Setup

Создайте проект GitLab для управления источника ваш Проект. Для получения дополнительной информации см. https://docs.gitlab.com/ee/README.html.

  1. Установите клиент Git.

  2. Настройте переходящий рабочий процесс. С GitLab, от основной ветви, создают временную ветвь для реализации изменений в файлах модели. Инженеры интегрирования могут использовать результаты испытаний Дженкинса решить, объединить ли временную ветвь в основную ветвь. Для получения дополнительной информации смотрите

    https://git-scm.com/book/en/v1/Git-Branching-Branching-Workflows.

  3. Под Settings> Repository, защитите основную ветвь путем осуществления использования запросов слияния, когда разработчики захотят объединить свои изменения в основную ветвь.

  4. Под Settings, на странице Integrations, добавляет webhook к URL вашего проекта Дженкинса. Этот webhook инициировал задание сборки на сервере Дженкинса.

Setup Дженкинса

Установите плагины GitLab и Касания. Модульный тест MATLAB использует TAPPlugin, чтобы передать результаты потоком к .tap файл. Чтобы включить коммуникацию тестового состояния от MATLAB до задания Дженкинса, Дженкинс импортирует .tap файл.

Создайте проект Дженкинса. Задайте эти настройки:

  1. В вашем проекте Дженкинса нажмите Configure.

  2. На вкладке General задайте название проекта.

  3. На вкладке Source Code Management, для поля Repository URL, задают URL вашего репозитория GitLab.

  4. На вкладке Build Triggers выберите Build when a change is pushed to GitLab.

  5. На вкладке Build выполните MATLAB, чтобы вызвать скрипт запуска. Скрипт запуска открывает проект и запускает все модульные тесты. Для проекта в этом примере код:

    matlab -nodisplay -r...
 "cd /var/lib/jenkins/workspace/'18b Metrics CI Demo'; run(true)"

  6. Во вкладке Post-build Actions сконфигурируйте плагин TAP, чтобы опубликовать результаты TAP Дженкинсу. В поле Test Results задайте reports/*.tap. Для Files to archive задайте reports/**,work/**.

    Плагин TAP показывает детали от Модульного теста MATLAB в расширенных результатах задания. Инфраструктура архивирования Дженкинса сохраняет выведенные артефакты, которые сгенерированы во время сборки Дженкинса.

Непрерывный рабочий процесс интегрирования

После подготовки вашего проекта Дженкинс и GitLab, следуют за непрерывным рабочим процессом интегрирования.

Фаза 1: разработка комплекта

  1. Создайте локальный клон репозитория GitLab. Смотрите Клон из Git-репозитория (MATLAB).

  2. В Simulink перейдите к локальному репозиторию GitLab.

  3. Создайте ветвь функции и файлы контроля и выборку. Смотрите Файлы Ветви и Слияния с Git (Simulink) и Получение по запросу, Нажатие и Файлы Выборки с Git (Simulink).

  4. Внесите любые необходимые изменения в файлы проекта.

  5. Симулируйте модель и подтвердите выход в Инспекторе Данных моделирования.

  6. Запустите модульные тесты MATLAB. Для получения дополнительной информации смотрите runtests.

  7. Добавьте и передайте модифицированные модели ветви функции. Смотрите Файлы Ветви и Слияния с Git (Simulink) и Получение по запросу, Нажатие и Файлы Выборки с Git (Simulink).

  8. Продвиньте изменения в репозитории GitLab. Смотрите Файлы Ветви и Слияния с Git (Simulink) и Получение по запросу, Нажатие и Файлы Выборки с Git (Simulink).

  9. В GitLab создайте запрос слияния. Выберите ветвь функции как исходную ветвь и целевую ветвь как ведущее устройство. Нажмите Compare Branches and Continue.

  10. Если опция не полностью реализована, отметьте запрос слияния как происходящая работа путем добавления букв WIP: в начале запроса. Если запрос слияния не отмечен WIP: это сразу инициировало сборку после создания.

  11. Нажмите Submit Merge Request.

Фаза 2: проверка при помощи непрерывного интегрирования

  1. Если буквы WIP: не в начале запроса слияния, команда нажатия инициировала сборку Дженкинса. В части Setup Дженкинса этого примера вы сконфигурировали Дженкинса, чтобы выполнить сборку, когда вы продвинули изменения в GitLab. Чтобы удалить буквы, нажмите Resolve WIP status.

  2. Перейдите к проекту Дженкинса. В Истории Сборки вы видите состояние сборки.

  3. Кликните по сборке.

  4. Нажмите Tap Test Results.

  5. В данном примере MetricThresholdGateway.m модульный тест не передал для трех метрик, потому что эти метрики не соответствовали порогам. Чтобы исследовать эти данные, необходимо загрузить данные локально.

Фаза 3: исследуйте проблемы качества локально

  1. Загрузите заархивированные результаты на локальную рабочую область репозитория Git.

  2. Разархивируйте загруженные файлы. Скопируйте reports/ и work/ папки к соответствующим папкам в локальном репозитории.

  3. Чтобы исследовать результаты, откройте проект и Метрическую Инструментальную панель.

  4. Чтобы разрешить непройденные тесты, сделайте необходимые обновления моделей. Продвиньте изменения в ветви функции в GitLab.

  5. Инженеры интегрирования могут использовать результаты испытаний Дженкинса решить, когда приемлемо выполнить слияние временной ветви в основную ветвь.

Смотрите также

|

Похожие темы

Документация Simulink Check
Поддержка
Для просмотра документации необходимо авторизоваться на сайте