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

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

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

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

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

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

Этот пример использует сервер непрерывного интегрирования Jenkins, чтобы запустить модульный тест MATLAB, чтобы определить, есть ли нарушения метрического порога. Jenkins архивирует результаты тестирования для вас, чтобы скачать и исследовать локально. 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
    На вкладке Project нажмите Startup Shudown. Для поля Startup files задайте 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
    На вкладке Project нажмите Startup Shudown. Для поля Shutdown files задайте cleanup.m файл.

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

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

Setup GitLab

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

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

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

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

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

  4. В разделе Settings на странице Integrations добавьте webhook к URL-адресу своего проекта Jenkins. Этот webhook запускает задание сборки на сервере Jenkins.

Setup Дженкинса

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

Создайте проект Дженкинса. Задайте следующие строения:

  1. В проекте Jenkins нажмите 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 в Jenkins. В поле Test Results задайте reports/*.tap. Для Files to archive задайте reports/**,work/**.

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

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

После настройки своего проекта, Jenkins и GitLab, следуйте рабочему процессу непрерывного интегрирования.

Фаза 1: Разработка функций

  1. Создайте локальный клон репозитория GitLab. См. раздел «Извлечение файлов из Git-репозитория».

  2. В Simulink перейдите в локальный репозиторий GitLab.

  3. Создайте ветвь функции, выберите и выпишите файлы. См. Ветвь и объединение файлов с Git и Pull, Push и Fetch Files с Git.

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

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

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

  7. Добавьте и фиксируйте измененные модели в ветви функции. См. Ветвь и объединение файлов с Git и Pull, Push и Fetch Files с Git.

  8. Внесите изменения в репозиторий GitLab. См. Ветвь и объединение файлов с Git и Pull, Push и Fetch Files с Git.

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

  10. Если функция не реализована в полном объеме, отметьте запрос на слияние как незавершенное произведение, добавив буквы WIP: в начале запроса. Если запрос слияния не помечен как НзП:, он сразу же запускает сборку после создания.

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

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

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

  2. Перейдите к проекту Дженкинса. В истории сборки можно увидеть статус сборки.

  3. Щелкните Сборка (Build).

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

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

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

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

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

  3. Чтобы исследовать результаты, откройте проект и панель Metrics Dashboard.

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

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

См. также

|

Похожие темы

Внешние веб-сайты

Simulink Check

Поддержка

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