Это не нужно делать. Походу мы запутались. Я выше скинул вопрос

То есть подразумевается, что любой коммит это production-ready коммит?

мб что бы заказчики  уже начали с чем то работать?

Именно

Но зачем?

Что бы ускорить процесс и улучшить фокус разработчиков на решении проблемы.

Ну ок ща попробую =\

А тестирование не входит в правильный CI? Staging не предусмотрен?

Короче я уже с полгода вяло валяю драйвер дисплея. (Железная реализация и сам протокол не  важны) - дисплей отдельное устройство, мк отправляет только состояние полей.
Да да это китайская HMI панель.
Я вот пытаюсь как то это все дело увязать в некий класс, но выходят переусложненные макароны.
К слову не очень важно, чем является это само устройство, т.к. я скорее хочу найти некий общий подход к подобным проблемам.

Я хочу, что бы
1) Было высокоуровневое АПИ для управления.
2) Данные принимались на вход в виде некие стандартизированные ( в устройстве ) сообщений.
3) Все это дело было слабо связано. Как с приложением, так и с железом.
4) Это скорее некий общий принцип, нежели частное решение.

У меня получились следующие абстракции.

1)  "Описание опции" - которая описывает некое нераздельное значение, которое должно отображаться\сохраняться.
В описании указаны IDшники, устройства\опции, глобальный и частные(соответствующие значениям на внешних устройствах) и информация о типе и размере значения.

2) Таблица описаний опций. Сидит в ПЗУ.

3) "Сообщение" - используется внутри устройства, несет в себе глобальный ID и некое значение опции.

4) "Устройства" - некие конечные точки, которые принимают и отдают сообщения.

5) "База данных" - строится на основе таблицы опций и содержит список опция-значение.
Принимает в себя сообщения с новыми значениями опции, сохраняет в себе и пересылает подписанным на изменения.
По факту является эдаким обсервер паттерном.

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

Отдельным костылем идут "команды" это сообщения устройство-устройство, в обход базы. Как их правильно всобачить пока не знаю. Разве некий "Роутер команд" делать.

Это немного к эмбедеду относится, но я постарался тут это максимально вырезать.

Входит. Но есть проблема семантических конфликтов которая решается тем что все как можно чаще и быстрее вливают все в мастер что бы код меньше расходился.

А на каком этапе от ревью до доставки на прод за день тестирование?

Staging не предусмотрен

На этапе автотестов.

А с джунами в команде такое будет работать?

Новая фича, ее должны покрыть автотестами ещё до ревью?

А у тебя есть ресурсы заниматься обучением джунов? Зачем их нанимать с такими вопросами

Да. В идеале не должно быть ревью как блокера к мерджу* но тут спорный момент

А какое это отношение имеет к проблеме? То есть надо начинать с того, что хороший CI - это команда без джунов?