Привет. Подскажите плиз чего можно почитать, посмотреть, послушать в плане организации релизнных циклов при продуктовой разработке, когда несколько команд разрабатывают один продукт.
У каждой команды есть своя специфик часть, но есть и общая часть, которая влияет на всех.
Команды хотят релизиться независимо друг от друга.

Вы собираетесь лечить проблему архитектуры и/или оргструктуры теребонькая релизные циклы?

Мне кстати тоже интересно, если есть какой-то курс университетский на курсере, было бы здорово.

Любой курс в котором рассматривается инкапсуляция

Начните с классики: ДДД Эванса, потом можно перейти к более современной литературе: Building Microservices: Designing Fine-Grained Systems

DDD, Conway's law, микросервисы

У людей проблемы в "толкании локтями" друг друга, скорее всего, тут надо не релизный цикл менять

Ну и мало инфы слишком. Что там за "общая часть". И почему команды "хотят" а не делают.

Да, и слово "релиз" без уточнения - смысла не имеет. Но об этом подробнее будет в следующем онлайне во вторник, подписывайтесь на наш канал (с)

Используем Agile Release Train. Посмотрите, может ответит на многие вопросы

Если у каждой команды есть свои [релизные] артефакты, то желания и капельки умения уже достаточно, чтобы их деплоить независимо.

Я допускаю, что может быть некое решение (многокомпонентное) где множество команд работает над одной ИС, но это заведомо очень сложная работа для архитектора. Ну например разработка ОС и там не смотря на то, что публичный релиз всей системы происходит одновременно, внутри вполне себе релизы компонентов идут независимо. В больших системах такие вопросы решаются инкапсуляцией и интерфейсами, но разработка в таком стиле требует высокой квалификации от того, кто разделяет систему на части

есть платформа как общая часть, где реализованы всякие фичи и есть другие модули, которые интегрированы с этой платформой по API или через брокер сообщений. Другие модули и компоненты живут в своих репозиториях и уже давно сами релизятся как хотят. А вот платформенная часть общая для всех и бывает так, что командам нужно в ней что-то допиливать. В этом случае релизы уже влияют на других.
До сего момента платформенная команда собирала сама все релизы платформы и всовывала туда задачи, ветки других. Но теперь хотим разделиться так, чтобы команды могли и сами это делать. Конечно придется командам самим регрессы гонять и поддерживать в актуальном состоянии, делить стенды, но может уже с таким сталкивались люди и сделали более оптимально.

Старайтесь минимизировать размер общей платформенной части, выносите из нее все, что можно вынести.

иногда лучше дублирование кода/логики

дубли можно оформить как либы и вынести их в отдельный гит репозиторий например..

Непонятно, зачем сразу затягивать в платформу то, что нужно отдельным командам? Пусть себе запилят, а там будет видно. Вообще выглядит как кривой дизайн и размазывание функционала. Практика показывает, что когда хотят куда-то в сторону воткнуть функционал, то решение так себе, надо остановиться и подумать. Но я понимаю, что думать некогда, надо фичи пилить 😅

Ну главное же не думать а писать код

Без всякого контекста, его спустят сверху в виде условия задачи, но видно вопрос задаёт тот кто не смог в условия задачи

common-epic-library-0.0.1-SNAPSHOT <- убийца ваших микросервисов