|  | 
| 
Модульный проект, разные репозитории для модулей | |||
|---|---|---|---|
| #18+ Всем привет! Есть проектик с Spring Cloud, модули в одном проекте и соответственно ветка в git одна. Есть желание, чтобы разные модули можно было коммитить в разные репозитории, предполагаю, что такая потребность возникала не у одного меня и возможность, скорее всего, такая есть. Может кто укажет направление куда двигаться? :) Очень не хочется создавать разные проекты для каждого сервиса и потом сидеть с кучей открытых инстансов Idea. ... | |||
| : 
 Нравится:
     Не нравится:
     | |||
| 07.11.2019, 10:35 |  | ||
| 
Модульный проект, разные репозитории для модулей | |||
|---|---|---|---|
| #18+ Nixic Есть проектик с Spring Cloud, ... | |||
| : 
 Нравится:
     Не нравится:
     | |||
| 07.11.2019, 10:41 |  | ||
| 
Модульный проект, разные репозитории для модулей | |||
|---|---|---|---|
| #18+ PetroNotC Sharp Nixic Есть проектик с Spring Cloud, Да он еще на стадии разработки, уже всё поднимается, но много всякого ... плохого кода внутри)) Хочется сразу разбить его так, чтобы девопсам жизнь облегчить ... | |||
| : 
 Нравится:
     Не нравится:
     | |||
| 07.11.2019, 10:53 |  | ||
| 
Модульный проект, разные репозитории для модулей | |||
|---|---|---|---|
| #18+ Nixic Хочется сразу разбить его так, чтобы девопсам жизнь облегчить Кстати, тут прогеры а не девопсы) ... | |||
| : 
 Нравится:
     Не нравится:
     | |||
| 07.11.2019, 11:12 |  | ||
| 
Модульный проект, разные репозитории для модулей | |||
|---|---|---|---|
| #18+ PetroNotC Sharp Nixic Хочется сразу разбить его так, чтобы девопсам жизнь облегчить Ну кто-то же должен настраивать всякие там докеры кубернетисы и т.д., а чтобы красиво им это преподносить, наш код должен правильнее пушиться, чтобы когда девопс всё настроит и ветки будут деплоиться сами(сейчас так и есть, но для монолита), то жевопс почти и не нужен ) ... | |||
| : 
 Нравится:
     Не нравится:
     | |||
| 07.11.2019, 11:19 |  | ||
| 
Модульный проект, разные репозитории для модулей | |||
|---|---|---|---|
| #18+ Nixic кубернетисы Ты кубернетис настроил? 10 докеров работают? 3 хоста для контейнеров есть? ... | |||
| : 
 Нравится:
     Не нравится:
     | |||
| 07.11.2019, 12:18 |  | ||
| 
Модульный проект, разные репозитории для модулей | |||
|---|---|---|---|
| #18+ Nixic Всем привет! Есть проектик с Spring Cloud, модули в одном проекте и соответственно ветка в git одна. Есть желание, чтобы разные модули можно было коммитить в разные репозитории, предполагаю, что такая потребность возникала не у одного меня и возможность, скорее всего, такая есть. Может кто укажет направление куда двигаться? :) Очень не хочется создавать разные проекты для каждого сервиса и потом сидеть с кучей открытых инстансов Idea. Вообще-то это холиварная тема. Монорепозитарий vs куча репозитариев. Для любого решения свои есть плюсы и минусы. ИМХО на начале удобнее монорепозитарий, потом по мере роста проекта бить его на логические части. Точнее, так. Проповедники микросеврисной архитектуры говорят, что надо начинать с монолита. Потом, когда будет понятно на какие домены делиться приложение/предметная область, тогда разделять монолит на микросервисы. Только после этого, можно разделить монорепозитарий на части. ... | |||
| : 
 Нравится:
     Не нравится:
     | |||
| 07.11.2019, 12:47 |  | ||
| 
Модульный проект, разные репозитории для модулей | |||
|---|---|---|---|
| #18+ Nixic Ну кто-то же должен настраивать всякие там докеры кубернетисы и т.д., а чтобы красиво им это преподносить, наш код должен правильнее пушиться, чтобы когда девопс всё настроит и ветки будут деплоиться сами(сейчас так и есть, но для монолита), то жевопс почти и не нужен ) За настройку приложения и оборачивания ее в докер отвесттвенность несет программист. DevOps предоставляет инфраструктуру. Т.е., например, кластер kubernetes и CI/CD. Даже скрипт деплоя на test/stage/prod по хорошему должен писать программист. ... | |||
| : 
 Нравится:
     Не нравится:
     | |||
| 07.11.2019, 12:51 |  | ||
| 
Модульный проект, разные репозитории для модулей | |||
|---|---|---|---|
| #18+ mad_nazgul Проповедники микросеврисной архитектуры говорят, что надо начинать с монолита. Монолит это везде Г архитектура. ... | |||
| : 
 Нравится:
     Не нравится:
     | |||
| 07.11.2019, 12:54 |  | ||
| 
Модульный проект, разные репозитории для модулей | |||
|---|---|---|---|
| #18+ PetroNotC Sharp Nixic кубернетисы Пока решается этот вопрос, с кубернетис я не сталкивался вообще, выбор конечный не за мной, сейчас у меня Spring cloud локально. PetroNotC Sharp Ты кубернетис настроил? нет PetroNotC Sharp  10 докеров работают? занимаюсь этим не я. PetroNotC Sharp  3 хоста для контейнеров есть? занимаюсь этим не я. Вообще изначально другой вопрос был, ну да ладно, хорошо, что и это затронули. Честно говоря, слаб я еще в этой теме... ... | |||
| : 
 Нравится:
     Не нравится:
     | |||
| 07.11.2019, 13:50 |  | ||
| 
Модульный проект, разные репозитории для модулей | |||
|---|---|---|---|
| #18+ PetroNotC Sharp mad_nazgul Проповедники микросеврисной архитектуры говорят, что надо начинать с монолита. Монолит это везде Г архитектура. Сэм Ньюман "Создание микросеврисов". Как раз об этом пишет в своей книге. А так монолит нормальная архитектура. "Прелесть" монолита в том, что если он плохо спроектирован, то работать будет долго. Хотя изменения будут стоить дорого. А вот плохо спроектированная "микросервисная" архитектура разваливается сразу. ... | |||
| : 
 Нравится:
     Не нравится:
     | |||
| 07.11.2019, 13:54 |  | ||
| 
Модульный проект, разные репозитории для модулей | |||
|---|---|---|---|
| #18+ mad_nazgul А так монолит нормальная архитектура. Монолит противоречит SOA. с какого года SOA? ... | |||
| : 
 Нравится:
     Не нравится:
     | |||
| 07.11.2019, 14:00 |  | ||
| 
Модульный проект, разные репозитории для модулей | |||
|---|---|---|---|
| #18+ mad_nazgul Сэм Ньюман ... | |||
| : 
 Нравится:
     Не нравится:
     | |||
| 07.11.2019, 14:00 |  | ||
| 
Модульный проект, разные репозитории для модулей | |||
|---|---|---|---|
| #18+ Nixic Честно говоря, слаб я еще в этой теме... Согласись. Нельзя учить прогеров если сам не писал. ... | |||
| : 
 Нравится:
     Не нравится:
     | |||
| 07.11.2019, 14:02 |  | ||
| 
Модульный проект, разные репозитории для модулей | |||
|---|---|---|---|
| #18+ mad_nazgul, Нашел. Монолит не пишут с 1998 года. Когда появилось Jini )))))) ... | |||
| : 
 Нравится:
     Не нравится:
     | |||
| 07.11.2019, 14:08 |  | ||
| 
Модульный проект, разные репозитории для модулей | |||
|---|---|---|---|
| #18+ PetroNotC Sharp mad_nazgul А так монолит нормальная архитектура. Монолит противоречит SOA. с какого года SOA? И в чем монолит противоречит SOA?! SOA можно и в виде монолита запилить. Oracle, IBM и RedHat как раз на основе своих монолитных решений предлагали SOA. ... | |||
| : 
 Нравится:
     Не нравится:
     | |||
| 07.11.2019, 14:53 |  | ||
| 
Модульный проект, разные репозитории для модулей | |||
|---|---|---|---|
| #18+ mad_nazgul SOA можно и в виде монолита запилить. Слово монолит придумал Ньюман? ... | |||
| : 
 Нравится:
     Не нравится:
     | |||
| 07.11.2019, 14:55 |  | ||
| 
Модульный проект, разные репозитории для модулей | |||
|---|---|---|---|
| #18+ mad_nazgul ИМХО на начале удобнее монорепозитарий, потом по мере роста проекта бить его на логические части. Точнее, так. Проповедники микросеврисной архитектуры говорят, что надо начинать с монолита. Потом, когда будет понятно на какие домены делиться приложение/предметная область, тогда разделять монолит на микросервисы. Только после этого, можно разделить монорепозитарий на части. Полностью согласен: в начале один репозиторий (как у ТС сейчас), а потом выделять отдельные подпроекты. С точки зрения работы с таким "многомодульным репозиторием" - git submodule . Одно уточнение - "разбивать" на подмодули я бы стал не по предметной области - доменам, а по "источникам изменений в проекте" или по аспектам, которые связаны с жизненным циклом проекта (это может быть и вопросы, связанные с развёртыванием проекта и др.). В общем, здесь нет универсального ответа, а есть только рекомендации: 1. Модуль должен быть условно самодостаточным (его можно отдельно собрать, протестировать (автотестами или вроде того) и установить/залить в репозиторий) 2. С модулем должна быть возможность работать НЕ в составе общего репозитория-объединения всех модулей (бывший монорепозиторий) 3. Точки разреза на модули должны быть понятными. Например, если вы просто разделили фронт и бэк, то явно об этом заявите. ... | |||
| : 
 Нравится:
     Не нравится:
     | |||
| 07.11.2019, 17:20 |  | ||
| 
Модульный проект, разные репозитории для модулей | |||
|---|---|---|---|
| #18+ qasta разбивать" на подмодули я бы стал не по предметной области - доменам, а по "источникам изменений в проекте" или по аспектам, которые связаны с жизненным циклом проекта (это может быть и вопросы, связанные с развёртыванием проекта и др.) ... | |||
| : 
 Нравится:
     Не нравится:
     | |||
| 07.11.2019, 17:35 |  | ||
| 
Модульный проект, разные репозитории для модулей | |||
|---|---|---|---|
| #18+ PetroNotC Sharp qasta разбивать" на подмодули я бы стал не по предметной области - доменам, а по "источникам изменений в проекте" или по аспектам, которые связаны с жизненным циклом проекта (это может быть и вопросы, связанные с развёртыванием проекта и др.) И да, и нет - по функционалу и по предметке имеет смысл разбивать, если именно они изменяются в проекте (мы говорим про "основной объем работ"). Например, в интеграционном решении предметная область может не изменяться годами, а вот точки интеграции добавляться и убираться раз в неделю :). Такой проект не стоит нарезать по предметке (но по функционалу - надо, если под этим термином понимать "функция интеграции с тем-то и тем-то"). Термины эти слишком широкие, поэтому, "и да, и нет" :) ... | |||
| : 
 Нравится:
     Не нравится:
     | |||
| 07.11.2019, 17:43 |  | ||
| 
Модульный проект, разные репозитории для модулей | |||
|---|---|---|---|
| #18+ qasta Например, в интеграционном решении Берем проект ИС Завод. Далее эту ИС по ГОСТ мы функционально описываем. Это и есть куски. Интегрировать проект ГОТОВЫЙ завод с 1С? Зачем тут такое рассматривать? ... | |||
| : 
 Нравится:
     Не нравится:
     | |||
| 07.11.2019, 17:56 |  | ||
| 
Модульный проект, разные репозитории для модулей | |||
|---|---|---|---|
| #18+ qasta Полностью согласен: в начале один репозиторий (как у ТС сейчас), а потом выделять отдельные подпроекты. С точки зрения работы с таким "многомодульным репозиторием" - git submodule . То есть нету одного репозитария. Сразу архитектор сделает 4 репо ОТДЕЛЬНЫХ. А потом при желании вставит один в другой подмодулем. Итого нет понятия Монорепозитарий и Монолит и Монолитные микросервисы (недавно было) ... | |||
| : 
 Нравится:
     Не нравится:
     | |||
| 07.11.2019, 17:59 |  | ||
| 
Модульный проект, разные репозитории для модулей | |||
|---|---|---|---|
| #18+ qasta Термины эти слишком широкие Пусть автор сделает 3 класса и 3 модуля. А потом вопрос задаёт. ... | |||
| : 
 Нравится:
     Не нравится:
     | |||
| 07.11.2019, 18:01 |  | ||
| 
Модульный проект, разные репозитории для модулей | |||
|---|---|---|---|
| #18+ PetroNotC Sharp Сразу архитектор сделает 4 репо ОТДЕЛЬНЫХ.  А потом при желании вставит один в другой подмодулем. Итого нет понятия Монорепозитарий и Монолит и Монолитные микросервисы (недавно было) У меня другой опыт и мнение. "Сразу архитектор сделает" - это далеко не всегда так (обычно угадать получается, но бывает по-разному). 1. Сначала - один репозиторий, который растёт, развивается, обретает какую-то структуру. Потому что так удобнее всего и вообще непонятно вначале - как надо нарезать. 2. Потом примерно становится понятной структура и возможные способы нарезки. Начинаем отделять один-два крупных модуля. В первом репозитории они подключаются гитовыми подмодулями (есть инструменты для гита - можно выделить новый репозиторий со всей историей из каталога, но это немного портит историю). При этом новый репозиторий можно скачать отдельно и работать только с ним. 3. Новые модули в проекте добавляются сразу в виде отдельных репозиториев, которые можно подключать в первый проект. А можно и не подключать - это уже как вам будет удобнее. ... | |||
| : 
 Нравится:
     Не нравится:
     | |||
| 07.11.2019, 18:15 |  | ||
| 
Модульный проект, разные репозитории для модулей | |||
|---|---|---|---|
| #18+ Nixic Всем привет! Есть проектик с Spring Cloud, модули в одном проекте и соответственно ветка в git одна. Есть желание, чтобы разные модули можно было коммитить в разные репозитории, предполагаю, что такая потребность возникала не у одного меня и возможность, скорее всего, такая есть. Может кто укажет направление куда двигаться? :) Очень не хочется создавать разные проекты для каждого сервиса и потом сидеть с кучей открытых инстансов Idea. Скорее всего тут единого решения не будет. А будет матрица стратегий с кучей ячеек где есть плюсы и минусы. Есть желание - надо трактовать как - "есть возможность выделить в проекте независимые части" которые компилируются и деплоятся например в локальный mvn/gradle repo независимо. Это хорошо. Это даёт разрабу концентрироваться на малой части исходного кода (когда фиксите ошибку) в полной уверенности что в другие модули лезть не надо там и так все гуд. Это плюс. С другой стороны отладчиком неудобно бегать если забыли запаблишить сорцы от всех модулей. Это минус. С другой стороны над модулем может рабоать отдельный разраб или тим. Это плюс. Еще с третьей стороны меж модулями можно ослаблять зависимости вплоть до 1 базового интерфейса с 1-2 методами. Это плюс. С четвертой стороны если что-то надо поменять в интерфейсе - надо много чего пересобрать и поломать и переключить мажорную версию билда. И проследить чтоб все модули подхватили. С пятой стороны - удобно для git когда проектов много. Может часть из них лежит даже в bitbucket. И имеют закрытые сорцы которые имеют статус ну.. если не тайны то хотя-бы нежелания пока их светить. Публичная часть - соотв в гитхабе. Это большой плюс. И так далее. ... | |||
| : 
 Нравится:
     Не нравится:
     | |||
| 07.11.2019, 18:35 |  | ||
|  | 

| start [/forum/search_topic.php?author=asp&author_mode=last_posts&do_search=1]: | 0ms | 
| get settings: | 9ms | 
| get forum list: | 12ms | 
| get settings: | 10ms | 
| get forum list: | 12ms | 
| check forum access: | 4ms | 
| check topic access: | 4ms | 
| track hit: | 41ms | 
| get topic data: | 11ms | 
| get forum data: | 3ms | 
| get page messages: | 62ms | 
| get tp. blocked users: | 1ms | 
| others: | 1122ms | 
| total: | 1291ms | 

| 0 / 0 | 
