Представитель Шуры Люберецкого в ЖЖ (brat_luber) wrote,
Представитель Шуры Люберецкого в ЖЖ
brat_luber

Category:

Теоретикам и практикам контроля версий

А вот вопрос созрел. Предположим, есть у нас вполне себе обычный IoTшный проект, состоящий из множества взаимосвязанных частей:

— схемотехника и печатная плата нескольких похожих устройств, библиотека компонентов для Eagle или DipTrace;
— прошивки — несколько, своя для каждого устройства (скорее всего, на базе Riot OS или Contiki, и возможно, с доработками самой ОС — то есть с ней обычно притаскивают целиком ее репозиторий);
— приложение для Android или какой-то там Progressive Web App;
— вебовский бекенд (скорее всего, на Django).

«Команда» — ну, по человеку (или по «полчеловека») на каждую из частей, проект новый, каждый взаимодействует с «соседями» (схемотехник-эмбеддер-фронтендер-бекендер). Вносят ли доработки в соседние части — возможно теоретически, но вряд ли.

Больше всего меня тут напрягает, что очень много вопросов будет «на стыке» частей (допустим, прошивка версии такой-то перестала работать с устройством версии такой-то, кто виноват?), в принципе, сюда просится монорепозиторий и общий для всех трекер задач — но как я представлю монорепу с вот этим всем, у меня глаз начинает дергаться. Общий трекер — возможно, но как оно будет жить с несколькими репозиториями для кода?

А как бы вы организовали контроль версий и трекинг задач в таком проекте? Интересуют все аспекты — от используемых инструментов до «оргмер».

Запись опубликована в блоге Шуры Люберецкого. Вы можете оставлять свои комментарии там или в ЖЖ.

Subscribe

  • Post a new comment

    Error

    default userpic

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 8 comments