Начало работы с DevOps для встраиваемых систем на примере ATmega328P

DevOps и методологии Agile преобразили разработку программного обеспечения, делая акцент на сотрудничестве, автоматизации и непрерывном улучшении. Применение принципов DevOps к моим проектам и дизайнам стало настоящим прорывом, повышая эффективность и надежность. В этой статье мы рассмотрим процесс настройки рабочего процесса непрерывной интеграции (CI) для существующего проекта встроенных систем, использующего микроконтроллер ATmega328P. К концу этой статьи вы увидите, как эти практики могут оптимизировать ваш процесс разработки и обеспечить высокое качество продуктов.

Понимание DevOps и Agile для встроенных систем

DevOps — это набор практик, популяризированных в мире программного обеспечения, который объединяет разработку программного обеспечения (Dev) и IT-операции (Ops) в непрерывный процесс. В мире программного обеспечения раньше было обычным разрабатывать программное обеспечение и «перебрасывать его через стену» к операционным специалистам для развертывания клиентам. DevOps предложил способ не только разрушить эту стену, но и автоматизировать весь процесс от начала до конца. В мире аппаратного обеспечения мы находим схожие моменты между разработкой продукта и производством, постоянно перебрасывая дизайн «через стену» к нашим инженерам по производству, чтобы убедиться, что все готово к производству.

В дизайне встроенных продуктов нам все еще нужно пройти наше программное обеспечение через производство, но сталкиваемся с вызовом двигаться быстрее, чем когда-либо, и обеспечивать максимально возможное качество. С принципами DevOps мы стремимся решить некоторые из этих вызовов.

• Зависимость от аппаратного обеспечения: Встроенные системы зависят от аппаратного обеспечения и конкретных ревизий этих печатных плат. Это может усложнить тестирование и развертывание, если не оптимизировать процессы для автоматизации и масштабируемости. Практики DevOps помогают автоматизировать эти процессы, используя одинаковую настройку как для аппаратного, так и для программного обеспечения, и проводя их через автоматизированные системы непрерывной интеграции (CI).
• Длительное время сборки: Настройка сборки встроенного программного обеспечения может быть сложной и приводить к длительным временам сборки. CI автоматизирует и ускоряет этот процесс, перенося сборки в облако и используя более мощные экземпляры, к которым разработчики обычно не имеют доступа.
• Ручное тестирование: Тестирование на реальном оборудовании необходимо, но часто является ручным, утомительным и занимает много времени. Автоматизация через тестирование с участием аппаратного обеспечения (HIL) повышает эффективность и точность и может быть передана настройке автоматизированного тестового оборудования, сконфигурированного с вашей системой CI.

Применяя принципы DevOps, мы можем быстро итерировать, используя методологии Agile в рамках парадигмы сборки-тестирования-развертывания для каждой дополнительной функции, которую мы хотим выпустить в производство.

Как это все работает

«Создание, тестирование и развертывание» — это распространенный набор слов, который вы часто слышите при обсуждении DevOps. Во встроенных системах мы делаем то же самое, поскольку наше развертывание также направлено в производство (а затем к конечному потребителю). В репозитории проекта мы используем Gitlab CI для управления нашим рабочим процессом Embedded DevOps от начала до конца. Мы используем то, что называется «пайплайнами», для создания задач, которые выполняют определенные задачи, такие как компиляция программного обеспечения, выполнение тестов на целевом устройстве или его выпуск в качестве официального пакета. В Gitlab пайплайн представляет собой набор задач, которые выполняются последовательно, как это:

Рисунок 1: Пример пайплайна, используемого в рабочем процессе ATmega328P DevOps в Gitlab

Вот разбивка скрипта CI (.gitlab-ci.yml файл), чтобы дать вам представление о том, как это работает.

• Docker: Как обсуждалось в Контейнеризация сред сборки и выполнения для тестирования в аппаратном цикле, этот этап создает образы Docker для создания стабильной среды для сборки, тестирования и прошивки кода. Это обеспечивает воспроизводимость процесса сборки на разных машинах и архитектурах (например, настольный ПК против Raspberry Pi).
• Тест: На этом этапе выполняются модульные тесты для проверки того, что ваш код делает то, что вы от него ожидаете. Автоматизированные тесты быстры и важны при изменении или рефакторинге существующего кода.
• Сборка: На этом этапе исходный код компилируется в двоичные файлы. В этом проекте генерируются артефакты, такие как .elf и .hex файлы, которые используются для прошивки чипа ATmega328P.
• HIL (Hardware-in-the-Loop): Этот этап включает тестирование программного обеспечения на реальном оборудовании, чтобы убедиться, что оно работает корректно в реальных условиях. Программное обеспечение загружается на оборудование и выполняются тесты для проверки функциональности, которую мы спроектировали, на конечном продукте.
• Развертывание: Этот этап управляет публикацией собранных артефактов в реестре пакетов, делая их доступными для использования.
• Выпуск: Этот этап создает новый релиз программного обеспечения, автоматизируя процесс доставки, чтобы обеспечить быстрые и надежные обновления. Это то, что производственная команда будет использовать для получения необходимой версии программного обеспечения для всей сборки продукта.

Мелкие детали

Есть некоторые мелкие детали, которые превращают этот рабочий процесс из простой реализации DevOps в плавно работающую, хорошо задокументированную и легко наблюдаемую систему. Есть несколько тонких деталей в рабочем процессе CI, на которые важно указать.

• Семантическое Версионирование: Установка версии, будь то с помощью автоматизированного механизма или вручную, чрезвычайно важна для цикла выпуска, особенно при работе с производством. Как пример, это устанавливается как переменная внутри скрипта CI и затем используется в задачах публикации и выпуска.
• Логика сборки Docker: Вы заметите, что есть блок логики, который используется для сборок контейнеров Docker:

if [ "$CI_COMMIT_REF_SLUG" == "$CI_DEFAULT_BRANCH" ]; then

  export IMAGE_TAG=$CI_REGISTRY_IMAGE/$IMAGE_TYPE:latest

else

  export IMAGE_TAG=$CI_REGISTRY_IMAGE/$IMAGE_TYPE:$CI_COMMIT_REF_SLUG

fi

Эта логика задаёт правило, согласно которому тег «latest» используется только для Docker-образа, собранного из главной ветки (т.е. после успешного прохождения запроса на слияние). Это гарантирует, что только успешные запросы на слияние публикуют самый последний и лучший Docker-образ, который используется всеми и во всех пайплайнах.

• Отчёты и покрытие: В современных системах непрерывной интеграции, таких как Gitlab, мы можем извлекать и отображать отчёты о тестировании и покрытии прямо в наших запросах на слияние и пайплайнах. Например, в этом запросе на слияние мы зафиксировали покрытие кода:

Рисунок 2: Покрытие кода в запросе на слияние

На этом скриншоте Gitlab подводит итоги тестов, выполненных на целевом оборудовании:

Рисунок 3: Сводка тестов, выполненных на целевом оборудовании

В конце концов, после того как наш код был проверен как с помощью модульного тестирования, так и на целевом оборудовании, этапы публикации и выпуска создают хорошо упакованный продукт, который может быть использован производственной командой:

Рисунок 4: Выпуск программного пакета

Благодаря всем этим автоматизированным шагам мы можем итеративно выпускать новые функции в духе Agile. Нет необходимости разрабатывать множество функций, отправлять их в отдел QA, а затем проводить рецензирование для выпуска пакета производственной командой. Всё это происходит в рамках одного рабочего процесса и полностью автоматизировано.

Заключение

В этой статье мы рассмотрели, как методологии DevOps и Agile могут быть применены к разработке встроенных систем, в частности, с использованием микроконтроллера ATmega328P. Мы обсудили преимущества внедрения рабочего процесса CI в Gitlab, который включает в себя автоматизацию, ускорение времени сборки и эффективное тестирование. Разбив CI-скрипт и объясняя каждый этап, мы показали, как создать надежный и оптимизированный процесс разработки, который повышает эффективность и качество продукта. Следуя этому практическому руководству (и исходному коду в репозитории), вы также должны быть в состоянии настроить собственный рабочий процесс Embedded DevOps.

Исходный код проекта можно найти здесь:https://gitlab.com/embedded-designs/atmega328p-serial-led-control.