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

Этот пример использование:

Этот пример показывает, как использовать Метрическую Инструментальную панель с инструментами 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
Поддержка
Для просмотра документации необходимо авторизоваться на сайте