Мне частенько приходится строить пайплайн для сборки проектов на Java. Иногда это опенсорс, иногда нет. Недавно я решил попробовать перенести часть своих репозиториев с Travis-CI и TeamCity на GitHub Actions, и вот что из этого получилось.
Как я уже рассказывал в прошлой части, при разработке IoT-проекта, протоколы взаимодействия с девайсами — вещь довольно нестабильная, и шансы потерять связь с тестовыми устройствами после обновления прошивки были довольно большие. Разработкой занималось несколько команд, и было жесткое требование — не терять возможность тестировать бизнес-слой приложения, даже если перепрошивка устройств переломает весь флоу работы с датчиками.
Для того, чтобы бизнес-аналитики могли тестировать свои гипотезы на более-менее похожих на реальность данных, мы построили имитационную модель устройства. Таким образом если устройство ломалось из-за новой прошивки, а данные необходимо было срочно получить, мы запускали в сеть имитационную модель заместо реального девайса, которая по старому формату гоняла данные и выдавала результат.
Продолжение первой части статьи «IoT там, где вы не ждали. Разработка и тестирование (часть 1)» не заставила себя долго ждать. На этот раз я расскажу, какая была архитектура проекта и на какие грабли мы наступили, когда начали тестировать наше решение.
