А вот вопрос созрел. Предположим, есть у нас вполне себе обычный IoTшный проект, состоящий из множества взаимосвязанных частей:
— схемотехника и печатная плата нескольких похожих устройств, библиотека компонентов для Eagle или DipTrace;
— прошивки — несколько, своя для каждого устройства (скорее всего, на базе Riot OS или Contiki, и возможно, с доработками самой ОС — то есть с ней обычно притаскивают целиком ее репозиторий);
— приложение для Android или какой-то там Progressive Web App;
— вебовский бекенд (скорее всего, на Django).
«Команда» — ну, по человеку (или по «полчеловека») на каждую из частей, проект новый, каждый взаимодействует с «соседями» (схемотехник-эмбеддер-фронтендер-бекендер). Вносят ли доработки в соседние части — возможно теоретически, но вряд ли.
Больше всего меня тут напрягает, что очень много вопросов будет «на стыке» частей (допустим, прошивка версии такой-то перестала работать с устройством версии такой-то, кто виноват?), в принципе, сюда просится монорепозиторий и общий для всех трекер задач — но как я представлю монорепу с вот этим всем, у меня глаз начинает дергаться. Общий трекер — возможно, но как оно будет жить с несколькими репозиториями для кода?
А как бы вы организовали контроль версий и трекинг задач в таком проекте? Интересуют все аспекты — от используемых инструментов до «оргмер».
Трекер лучше отдельный общий, возможно с интеграцией типа » #1488 fixed» помечает таск закрытым.
Софтовые репы порезать на разумные куски, по возможности без сабмодулей(я в виду на виду имел это кривое говно если говорим про гит), уж лучше обмазать небольшими скриптами котоыре выдёргивают нужные ревизии указанные, например в файлике рядом.
Железячное я бы держал в отдельных репах, или если альтиум, то в его хранилке поверх svn, иначе там содомия получается. Игл и диптрейс не трогал, но если там бинарные файлы плат/схем — то всё равно будет содомия.