Непрерывная Интеграция — Лучшие Практики Ci Для Встраиваемых Платформ (Esp32/Arduino)

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

По своему опыту я уже отказался от Arduino IDE в пользу использования платформыIO с VS Code, поскольку, что касается CI, она обеспечивает улучшенную установку зависимостей и автоматизацию конфигурации сборки.

Вопрос в том, какие инструменты и процессы уже существуют и какие можно перепрофилировать для использования в рамках Arduino, чтобы обеспечить CI, как и в веб-разработке.

Мета: следующей наиболее актуальной группой обмена стеками будет IoT, но ни в одном сообщении не упоминается непрерывная интеграция.

#непрерывная-интеграция #тестирование #управление конфигурацией

Поскольку «развертывание» на IoT-устройство, особенно массовое, не будет производиться с помощью CI-системы. Тогда цель системы CI в основном состоит в том, чтобы убедиться, что она воля работай нормально.

Это означает, что вам в основном нужно запустить некоторые тесты с использованием CI. Автоматическое тестирование определенно возможно, как для модульных, так и для интеграционных тестов.

Самым важным для модульных тестов обычно является очень короткое время выполнения и короткий цикл обратной связи. Для большой кодовой базы, если есть возможность скомпилировать ее части с помощью родного компилятора хоста и запускать там модульные тесты — отличный вариант. При необходимости вы также можете выполнить кросс-компиляцию на целевой платформе и запустить модульные тесты с помощью какого-нибудь эмулятора, чтобы получить необходимую скорость. Все это может произойти во время задания CI «сборка+тестирование». Компиляция для целевого объекта и запуск модульных тестов на целевом объекте будут просто мучительно медленными, если все сделано правильно, но это также можно сделать - просто убедитесь, что вы прошиваете только наименьший возможный фрагмент кода и отправляете отчет через последовательный порт, над которым он работал. устройство.

Для интеграционных тестов, если возможно установить код на реальном устройстве и пообщаться с ним через последовательный интерфейс, вы можете убедиться, что код действительно работает на целевом устройстве. Если по какой-то причине код дает сбой или работает некорректно, возможно, потребляет слишком много энергии и/или перезапускается, то интеграционные тесты это уловят. Вы также можете использовать другое тестовое устройство, выполняющее измерения и предоставляющее отчеты через последовательный интерфейс для задания CI. Можно использовать Arduino или другой ESP для измерения напряжения и/или силы тока во время выполнения частей вашего кода и проверки их на соответствие известным правильным значениям. Вы не ожидаете, что устройство будет потреблять 400 мА, например, в режиме глубокого сна, это легко проверить с помощью «тестового жгута».

Все эти модульные и интеграционные тесты могут запускаться полностью автоматически на CI-сервере. Естественно, вы, вероятно, будете использовать этот «сервер» локально и не будете полагаться на облачное решение, которое может поддерживать или не поддерживать ваше последнее интеграционное тестирование.

С аппаратным обеспечением дымовые тесты становятся более «реальными», поскольку вы действительно можете подключить устройство и увидеть, как выходит волшебный дым. Обычно вам даже не нужно запускать код до того, как он сгорит, поскольку проблема часто кроется в аппаратном обеспечении.

Поскольку я упомянул тестирование, существует также интеграционное тестирование, которое выполняется на аппаратном уровне. Если у вас есть хорошее тестовое оборудование, которое проверяет работоспособность устройства путем его проверки, вы можете использовать тот же тестовый комплект для проведения цикла контроля качества на заводе, где они производят устройства позже. Информации о создании этих стендов довольно много. Один из примеров этого здесь - https://www.sparkfun.com/tutorials/138.

Из вашего комментария

Я надеялся на модульные тесты целевого кода, некоторый анализ в стиле valgrind вплоть до CD.

у меня был ответ на упомянутый вопрос Arduino StackExchange, который касается некоторых из этих проблем. Но с момента написания этого ответа я добавил некоторые функции проверки памяти в

==2284==ERROR: AddressSanitizer: heap-use-after-free on address 0x603000000280 at pc 
0x0001032b987e bp 0x7ffeec94c0b0 sp 0x7ffeec94c0a8
READ of size 1 at 0x603000000280 thread T0

#0 0x1032b987d in Adafruit_WS2801::show() Adafruit_WS2801.cpp:203

#1 0x1032b84b1 in Strip::init(unsigned char, unsigned char) Strip.cpp:10

#2 0x1032baaff in test_set_strip_values::task() strip.cpp:10

#3 0x1032bd900 in Test::test() ArduinoUnitTests.h:165

#4 0x1032bcfd4 in Test::run(Test::ReporterTAP*) ArduinoUnitTests.h:137

#5 0x1032bcb79 in Test::run_and_report(int, char**) ArduinoUnitTests.h:155

#6 0x1032bcab8 in main strip.cpp:43

#7 0x7fff769d0114 in start (libdyld.dylib:x86_64+0x1114)

Хотя он не выполняет статический анализ, он может обнаруживать определенные виды проблем с памятью при выполнении модульных тестов:

arduino_ci

Больше контекста в запрос на включение, который решает эту проблему