Часто слышал мнение, что в embedded программировании в принципе не может быть никакого DevOps(а). Якобы вот есть GUI(ня) в IAR и там надо много мышкой водить. "Ты же не будешь ставить шаговые двигатели для сдвигания мышки" и т. п.
В этом тексте я намерен пофантазировать каким мог бы быть абстрактный процесс разработки firmware с точки зрения DevOps. И перечислить атрибуты такого процесса.
Сложным, дорогостоящиям и требующим длительной разработки техническим системам для проверки и подтверждения работоспособности архитектуры нужны тщательные и надежные тесты. Но по мере усложнения современных систем, особенно в случае программного обеспечения, об этом критическом шаге проще говорить, чем действительно его сделать.
Представьте себе тестирование электронных компонентов нового автомобиля. Чтобы оставаться актуальными на современном рынке, современные автомобили должны включать в себя современные системы помощи водителю (ADAS), камеры, радары и многое другое. Тестирование этих подсистем на собранном продукте в желаемых сценариях использования гарантирует, что испытания проводятся в идеальном контексте, но оно также влечет за собой значительные накладные расходы и сложность проверки каждого сценария.
Откладывание испытаний до окончательной сборки сопряжено со значительным риском, а изменения, которые необходимо внести по результатам испытаний, могут привести к катастрофическим последствиям для графика. Обязательно нагрянут немыслимая стоимость тестирования и неопределенность времени выхода на рынок. Сложность этой проблемы возрастает еще больше, если учесть, что каждый элемент из множества электронных блоков управления (ECU) в автомобиле работает с огромным количеством сигналов, представляющих различные функции и типы входов/выходов, что затрудняет тестирование с полным покрытием. Все эти факторы приводят к формированию нерешаемой задачи, ставящей под сомнение возможность тщательного тестирования, которое будет эффективным с точки зрения затрат и времени.
Читать полностью »
