powered by simpleCommunicator - 2.0.30     © 2024 Programmizd 02
Map
Форумы / Java [игнор отключен] [закрыт для гостей] / Модульный проект, разные репозитории для модулей
25 сообщений из 39, страница 1 из 2
Модульный проект, разные репозитории для модулей
    #39886096
Nixic
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Всем привет!
Есть проектик с Spring Cloud, модули в одном проекте и соответственно ветка в git одна.
Есть желание, чтобы разные модули можно было коммитить в разные репозитории, предполагаю, что такая потребность возникала не у одного меня и возможность, скорее всего, такая есть.
Может кто укажет направление куда двигаться? :) Очень не хочется создавать разные проекты для каждого сервиса и потом сидеть с кучей открытых инстансов Idea.
...
Рейтинг: 0 / 0
Модульный проект, разные репозитории для модулей
    #39886101
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Nixic
Есть проектик с Spring Cloud,
ты вроде один такой крутой)
...
Рейтинг: 0 / 0
Модульный проект, разные репозитории для модулей
    #39886116
Nixic
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PetroNotC Sharp
Nixic
Есть проектик с Spring Cloud,
ты вроде один такой крутой)

Да он еще на стадии разработки, уже всё поднимается, но много всякого ... плохого кода внутри)) Хочется сразу разбить его так, чтобы девопсам жизнь облегчить
...
Рейтинг: 0 / 0
Модульный проект, разные репозитории для модулей
    #39886123
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Nixic
Хочется сразу разбить его так, чтобы девопсам жизнь облегчить
в книжках пишут, что spring cloud data flow наоборот, убирает девопсов. Или когда их вообще нет.
Кстати, тут прогеры а не девопсы)
...
Рейтинг: 0 / 0
Модульный проект, разные репозитории для модулей
    #39886126
Nixic
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PetroNotC Sharp
Nixic
Хочется сразу разбить его так, чтобы девопсам жизнь облегчить
в книжках пишут, что spring cloud data flow наоборот, убирает девопсов. Или когда их вообще нет.

Ну кто-то же должен настраивать всякие там докеры кубернетисы и т.д., а чтобы красиво им это преподносить, наш код должен правильнее пушиться, чтобы когда девопс всё настроит и ветки будут деплоиться сами(сейчас так и есть, но для монолита), то жевопс почти и не нужен )
...
Рейтинг: 0 / 0
Модульный проект, разные репозитории для модулей
    #39886145
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Nixic
кубернетисы
это и есть менеджер докеров. Причем тут спринг?
Ты кубернетис настроил?
10 докеров работают?
3 хоста для контейнеров есть?
...
Рейтинг: 0 / 0
Модульный проект, разные репозитории для модулей
    #39886160
mad_nazgul
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Nixic
Всем привет!
Есть проектик с Spring Cloud, модули в одном проекте и соответственно ветка в git одна.
Есть желание, чтобы разные модули можно было коммитить в разные репозитории, предполагаю, что такая потребность возникала не у одного меня и возможность, скорее всего, такая есть.
Может кто укажет направление куда двигаться? :) Очень не хочется создавать разные проекты для каждого сервиса и потом сидеть с кучей открытых инстансов Idea.


Вообще-то это холиварная тема. Монорепозитарий vs куча репозитариев.
Для любого решения свои есть плюсы и минусы.

ИМХО на начале удобнее монорепозитарий, потом по мере роста проекта бить его на логические части.
Точнее, так. Проповедники микросеврисной архитектуры говорят, что надо начинать с монолита.
Потом, когда будет понятно на какие домены делиться приложение/предметная область, тогда разделять монолит на микросервисы.
Только после этого, можно разделить монорепозитарий на части.
...
Рейтинг: 0 / 0
Модульный проект, разные репозитории для модулей
    #39886163
mad_nazgul
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Nixic
Ну кто-то же должен настраивать всякие там докеры кубернетисы и т.д., а чтобы красиво им это преподносить, наш код должен правильнее пушиться, чтобы когда девопс всё настроит и ветки будут деплоиться сами(сейчас так и есть, но для монолита), то жевопс почти и не нужен )


За настройку приложения и оборачивания ее в докер отвесттвенность несет программист.

DevOps предоставляет инфраструктуру.
Т.е., например, кластер kubernetes и CI/CD.

Даже скрипт деплоя на test/stage/prod по хорошему должен писать программист.
...
Рейтинг: 0 / 0
Модульный проект, разные репозитории для модулей
    #39886169
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mad_nazgul
Проповедники микросеврисной архитектуры говорят, что надо начинать с монолита.
не слышал.
Монолит это везде Г архитектура.
...
Рейтинг: 0 / 0
Модульный проект, разные репозитории для модулей
    #39886202
Nixic
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PetroNotC Sharp
Nixic
кубернетисы
это и есть менеджер докеров. Причем тут спринг?

Пока решается этот вопрос, с кубернетис я не сталкивался вообще, выбор конечный не за мной, сейчас у меня Spring cloud локально.
PetroNotC Sharp
Ты кубернетис настроил?

нет
PetroNotC Sharp
10 докеров работают?

занимаюсь этим не я.
PetroNotC Sharp
3 хоста для контейнеров есть?

занимаюсь этим не я.

Вообще изначально другой вопрос был, ну да ладно, хорошо, что и это затронули.
Честно говоря, слаб я еще в этой теме...
...
Рейтинг: 0 / 0
Модульный проект, разные репозитории для модулей
    #39886206
mad_nazgul
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PetroNotC Sharp
mad_nazgul
Проповедники микросеврисной архитектуры говорят, что надо начинать с монолита.
не слышал.
Монолит это везде Г архитектура.


Сэм Ньюман "Создание микросеврисов". Как раз об этом пишет в своей книге.

А так монолит нормальная архитектура.

"Прелесть" монолита в том, что если он плохо спроектирован, то работать будет долго. Хотя изменения будут стоить дорого.
А вот плохо спроектированная "микросервисная" архитектура разваливается сразу.
...
Рейтинг: 0 / 0
Модульный проект, разные репозитории для модулей
    #39886211
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mad_nazgul
А так монолит нормальная архитектура.
Ещё раз
Монолит противоречит SOA.
с какого года SOA?
...
Рейтинг: 0 / 0
Модульный проект, разные репозитории для модулей
    #39886213
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mad_nazgul
Сэм Ньюман
не читай его.
...
Рейтинг: 0 / 0
Модульный проект, разные репозитории для модулей
    #39886215
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Nixic
Честно говоря, слаб я еще в этой теме...
ну дак рано вопрос поднял про оркестрацию.
Согласись.
Нельзя учить прогеров если сам не писал.
...
Рейтинг: 0 / 0
Модульный проект, разные репозитории для модулей
    #39886220
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mad_nazgul,
Нашел.
Монолит не пишут с 1998 года. Когда появилось Jini
))))))
...
Рейтинг: 0 / 0
Модульный проект, разные репозитории для модулей
    #39886244
mad_nazgul
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PetroNotC Sharp
mad_nazgul
А так монолит нормальная архитектура.
Ещё раз
Монолит противоречит SOA.
с какого года SOA?


И в чем монолит противоречит SOA?!
SOA можно и в виде монолита запилить.
Oracle, IBM и RedHat как раз на основе своих монолитных решений предлагали SOA.
...
Рейтинг: 0 / 0
Модульный проект, разные репозитории для модулей
    #39886246
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mad_nazgul
SOA можно и в виде монолита запилить.
не верю.
Слово монолит придумал Ньюман?
...
Рейтинг: 0 / 0
Модульный проект, разные репозитории для модулей
    #39886336
qasta
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
mad_nazgul

ИМХО на начале удобнее монорепозитарий, потом по мере роста проекта бить его на логические части.
Точнее, так. Проповедники микросеврисной архитектуры говорят, что надо начинать с монолита.
Потом, когда будет понятно на какие домены делиться приложение/предметная область, тогда разделять монолит на микросервисы.
Только после этого, можно разделить монорепозитарий на части.


Полностью согласен: в начале один репозиторий (как у ТС сейчас), а потом выделять отдельные подпроекты.
С точки зрения работы с таким "многомодульным репозиторием" - git submodule .

Одно уточнение - "разбивать" на подмодули я бы стал не по предметной области - доменам, а по "источникам изменений в проекте" или по аспектам, которые связаны с жизненным циклом проекта (это может быть и вопросы, связанные с развёртыванием проекта и др.). В общем, здесь нет универсального ответа, а есть только рекомендации:
1. Модуль должен быть условно самодостаточным (его можно отдельно собрать, протестировать (автотестами или вроде того) и установить/залить в репозиторий)
2. С модулем должна быть возможность работать НЕ в составе общего репозитория-объединения всех модулей (бывший монорепозиторий)
3. Точки разреза на модули должны быть понятными. Например, если вы просто разделили фронт и бэк, то явно об этом заявите.
...
Рейтинг: 0 / 0
Модульный проект, разные репозитории для модулей
    #39886351
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
qasta
разбивать" на подмодули я бы стал не по предметной области - доменам, а по "источникам изменений в проекте" или по аспектам, которые связаны с жизненным циклом проекта (это может быть и вопросы, связанные с развёртыванием проекта и др.)
если не по функционалу или предметке, то связи будут тесными и угробят всю модульность.
...
Рейтинг: 0 / 0
Модульный проект, разные репозитории для модулей
    #39886358
qasta
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
PetroNotC Sharp
qasta
разбивать" на подмодули я бы стал не по предметной области - доменам, а по "источникам изменений в проекте" или по аспектам, которые связаны с жизненным циклом проекта (это может быть и вопросы, связанные с развёртыванием проекта и др.)
если не по функционалу или предметке, то связи будут тесными и угробят всю модульность.


И да, и нет - по функционалу и по предметке имеет смысл разбивать, если именно они изменяются в проекте (мы говорим про "основной объем работ"). Например, в интеграционном решении предметная область может не изменяться годами, а вот точки интеграции добавляться и убираться раз в неделю :). Такой проект не стоит нарезать по предметке (но по функционалу - надо, если под этим термином понимать "функция интеграции с тем-то и тем-то"). Термины эти слишком широкие, поэтому, "и да, и нет" :)
...
Рейтинг: 0 / 0
Модульный проект, разные репозитории для модулей
    #39886367
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
qasta
Например, в интеграционном решении
давай не будем про африканцев, если мы в европе.
Берем проект ИС Завод.
Далее эту ИС по ГОСТ мы функционально описываем.
Это и есть куски.
Интегрировать проект ГОТОВЫЙ завод с 1С?
Зачем тут такое рассматривать?
...
Рейтинг: 0 / 0
Модульный проект, разные репозитории для модулей
    #39886380
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
qasta
Полностью согласен: в начале один репозиторий (как у ТС сейчас), а потом выделять отдельные подпроекты.
С точки зрения работы с таким "многомодульным репозиторием" - git submodule .
многомодульные в git состоят из отдельных репо.
То есть нету одного репозитария.
Сразу архитектор сделает 4 репо ОТДЕЛЬНЫХ.
А потом при желании вставит один в другой подмодулем.
Итого нет понятия Монорепозитарий и Монолит и Монолитные микросервисы (недавно было)
...
Рейтинг: 0 / 0
Модульный проект, разные репозитории для модулей
    #39886386
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
qasta
Термины эти слишком широкие
согласен.
Пусть автор сделает 3 класса и 3 модуля.
А потом вопрос задаёт.
...
Рейтинг: 0 / 0
Модульный проект, разные репозитории для модулей
    #39886411
qasta
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
PetroNotC Sharp
Сразу архитектор сделает 4 репо ОТДЕЛЬНЫХ.
А потом при желании вставит один в другой подмодулем.
Итого нет понятия Монорепозитарий и Монолит и Монолитные микросервисы (недавно было)


У меня другой опыт и мнение. "Сразу архитектор сделает" - это далеко не всегда так (обычно угадать получается, но бывает по-разному).
1. Сначала - один репозиторий, который растёт, развивается, обретает какую-то структуру. Потому что так удобнее всего и вообще непонятно вначале - как надо нарезать.
2. Потом примерно становится понятной структура и возможные способы нарезки. Начинаем отделять один-два крупных модуля. В первом репозитории они подключаются гитовыми подмодулями (есть инструменты для гита - можно выделить новый репозиторий со всей историей из каталога, но это немного портит историю). При этом новый репозиторий можно скачать отдельно и работать только с ним.
3. Новые модули в проекте добавляются сразу в виде отдельных репозиториев, которые можно подключать в первый проект. А можно и не подключать - это уже как вам будет удобнее.
...
Рейтинг: 0 / 0
Модульный проект, разные репозитории для модулей
    #39886424
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Nixic
Всем привет!
Есть проектик с Spring Cloud, модули в одном проекте и соответственно ветка в git одна.
Есть желание, чтобы разные модули можно было коммитить в разные репозитории, предполагаю, что такая потребность возникала не у одного меня и возможность, скорее всего, такая есть.
Может кто укажет направление куда двигаться? :) Очень не хочется создавать разные проекты для каждого сервиса и потом сидеть с кучей открытых инстансов Idea.

Скорее всего тут единого решения не будет. А будет матрица стратегий с кучей ячеек где есть плюсы и минусы.

Есть желание - надо трактовать как - "есть возможность выделить в проекте независимые части" которые компилируются
и деплоятся например в локальный mvn/gradle repo независимо. Это хорошо. Это даёт разрабу концентрироваться
на малой части исходного кода (когда фиксите ошибку) в полной уверенности что в другие модули лезть не надо
там и так все гуд. Это плюс.
С другой стороны отладчиком неудобно бегать если забыли запаблишить сорцы от всех модулей. Это минус.
С другой стороны над модулем может рабоать отдельный разраб или тим. Это плюс.
Еще с третьей стороны меж модулями можно ослаблять зависимости вплоть до 1 базового интерфейса с 1-2 методами.
Это плюс.
С четвертой стороны если что-то надо поменять в интерфейсе - надо много чего пересобрать и поломать и
переключить мажорную версию билда. И проследить чтоб все модули подхватили.
С пятой стороны - удобно для git когда проектов много. Может часть из них лежит даже в bitbucket. И имеют
закрытые сорцы которые имеют статус ну.. если не тайны то хотя-бы нежелания пока их светить.
Публичная часть - соотв в гитхабе. Это большой плюс.
И так далее.
...
Рейтинг: 0 / 0
25 сообщений из 39, страница 1 из 2
Форумы / Java [игнор отключен] [закрыт для гостей] / Модульный проект, разные репозитории для модулей
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]