LINUX.ORG.RU
ФорумTalks

Пощупал ынтырпрайс ERP известного финансового конгломерата

 , , , ,


0

2

Пощупал корпоративную ынтырпрайс ERP систему известного транснационального финансового конгломерата. Написано это убожество на Java 5.

Казалось бы - простейшая задача: поменять user и password для database connection для деплоя в тестовое окружения.

Ага щаз: оказывается эти credentianals разбросаны по всему проекту. И их примерно 1600 штук. Как в джава коде, так и xml конфигах Томката.

Вы сейчас мне скажете - делай новый бранч в гите и меняй все Find & Replace .. ом, commit и вуаля - женька билдит артефакты тестовой сборки из той бранчи.

Но дело в том, что у нас тут не сбертех, а конгломерат. И гита у нас нет. И не будет в ближайшие 30 лет. А есть Subversion. Где фактически нет бранчей. И все коммитится в мастер.

Чешу репу и хочу уйти назад в микросервисы на ноде. Там хоть конфиги есть. Да.



Последнее исправление: GP (всего исправлений: 1)

Кто-то когда-то что-то наговнякал, далее это поделие не поддерживали должным образом и оно превратилось в устаревшее говно. Вполне очевидный результат.

Irben ★★★
()
Ответ на: комментарий от qulinxao3

Патриот встал, монолит упал, отжался, но встал только утром.

А могу бы под присмотром кубера отжиматься.

GP
() автор топика
Ответ на: комментарий от Irben

Ваши предложения по поводу рефакторинга монолита в микросервисы? Вы уже проанализировали ваше решение на антипаттерн Макросервис? Во сколько сторипоинтов оцениваете?

GP
() автор топика

А есть Subversion. Где фактически нет бранчей. И все коммитится в мастер.

Есть там бранчи. Может не такие модные, но есть. Svn cp и вперёд

upcFrost ★★★★★
()
Ответ на: комментарий от GP

Микросервисы не панацея, монолит на них попилить бывает сложнее чем с нуля написать ещё один монолит

upcFrost ★★★★★
()
Ответ на: комментарий от GP

Блин, ребят, как вы достали этот кубер поминать, между делом, будто это связи с аппаратом президента.
Ну типа я жру говно на шестой джаве с сабвершином, гита не будет ещё 30 лет, но вот когда моя секретарша просит принять звоночек от кубера…

system-root ★★★★★
()
Ответ на: комментарий от GP

Ваши предложения по поводу рефакторинга монолита в микросервисы?

На основе топика могу сказать, что автор перевозбуждён и надо успокоиться. Далее генерировать задачи на обновление монолита до приемлимого состояния. Продукт овнер увидит, насколько большая работа всё это дело привести в актуальное состояние и, быть может, согласиться начать переписывать отдельные части монолита на что-то более современное.

Я сам провёл не мало проектов по раздербаниванию устаревших монолитов в нечто более современное, какие-то из этих проекты даже полностью завершились в течении нескольких лет. Работа долгая, муторная и приходится больше договариваться, согласовывать миграции и искать подводные камни, нежели разрабатывать собственно новые компоненты / сервисы, которые заменят устаревший функционал.

Irben ★★★
()

Любой продукт, который живёт давно и лет хотя бы 10 как перестал активно разрабатываться, а только кусками что-то допиливается и каждый это допиливание поручают новой команде превращается в то, что ты описал. Постоянно сталкиваюсь с подобным и ничего особенного в этом нет. Решает тут только кропотливая работа. А это значит, что заказчик должен выделить бюджет. Будет бюджет, будет и кусок окаменелости переведён на современную яву, нормально проапгрейжен и всё говно удалено. А частями и может быть монолит чуток распилен на более поддерживаемые части.

Думаешь рой микросервисов через 15 лет не будет выглядеть также плохо? А вот и нет. Будет, и конфиги будут в разных местах, и деплоиться будет всё это чёрт знает как, и захардкоденные параметры будут, потому что это всё зависит от людей, а люди как были, такие они и есть. Хоть на java, хотья на php, хоть на ts, хоть на go - всё те же самые люди. Притом пару роев микросервисов 15-20 лет отроду точно будет сложнее отлаживать. И тут целая туча причин. Например так ли будет легко это всё запустить, если оно будет тянуть за собой древний nodejs или go? С java, oracle, mssql, mysql, php то всё более-менее неплохо. Некоторые проекты даже можно на современном окружении почти без бубна или парой бубнов запустить и продолжить разрабатывать. А вот код с микросервисами будут очень много засад. Как бы не пришлось всё это дело пускать в виртуалках со старым окружением и отлаживать весь этот ад через ssh.

PS: всё дело в возрасте софта, квалификации разработчиков и изначальном бюджете проекта. Всё остальное вторично.

ixrws ★★★
()
Ответ на: комментарий от upcFrost

:) у человека проблема сделать серч энд риплейз, а ты ему такие страшные вещи рассказываешь.

Наверное только вдоль можно посоветовать.

mrdeath ★★★★★
()
Ответ на: комментарий от mrdeath

Но ведь делать реверт коммита для отмены изменений в мастер бранче Svn это же так не стильно, модно и молодежно.

Дело ведь не в S&R.

GP
() автор топика
Последнее исправление: GP (всего исправлений: 1)
Ответ на: комментарий от upcFrost

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

GP
() автор топика

Subversion. Где фактически нет бранчей.

Поржал.

В ЛОЛксы!

grim ★★☆☆
()
Ответ на: комментарий от GP

я не совсем понимаю чем плохо делать реверт в svn. До гита все писали в svn и ничего не было страшного.

mrdeath ★★★★★
()
Ответ на: комментарий от GP

Который конечно же искапорки умеет так же хорошо детектить бранчи Svn, как и git.

Тебя отсутствие dropdown менюшки пугает? Не, с гитом там работа проще несколько, но судя по количеству кода и возрасту проекта которые ты описал этот гит у тебя займёт так что мама не горюй

Короче не ной, svn и svn. Не патчи же по почте.

upcFrost ★★★★★
()

Где тэг ERP? Мне в оповещения не пришло, а ваши жавы с микросервисами я в гробу видал.

byko3y ★★★★
()

Ага щаз: оказывается эти credentianals разбросаны по всему проекту. И их примерно 1600 штук. Как в джава коде, так и xml конфигах Томката
Вы сейчас мне скажете - делай новый бранч в гите и меняй все Find & Replace .. ом, commit и вуаля

Казалось бы, при чем тут вообще Git? Что Git тебе не позволил подпереть говно костылями и дальше делать вид, что так и надо? А есть люди, которые хранят в Git шаблоны, при деплое подставляя в них логин-пароль.

По канону логин-пароль должен храниться в каком-нибудь settings.xml, и подхватываться оттуда без пересборки. Всё остальное — это дичь, и лично твоя вина в том, что ты не докладываешь об этом начальству.

Но дело в том, что у нас тут не сбертех, а конгломерат. И гита у нас нет. И не будет в ближайшие 30 лет. А есть Subversion. Где фактически нет бранчей. И все коммитится в мастер

Представь себе, гугл тоже так работает. И даже Microsoft так работает, хоть и купил github. Потому что секс с кучей веток никому не в кайф, потому что разрабы хотят видеть единую и линейную историю изменений, желательно состоящих из внесений законченных фич, а не промежуточных правок из одной строчки. Разрабы хотят просто приходит на работу, синхронизироваться с общей репой, и быть уверенным, что этот код рабочий и актуальный, что они не подхватят какую-то неподдерживаемую комбинацию ревизий/веток из разных репозиториев — по этой причине помимо единой ветки используется еще и монорепозиторий для всех подпроектов, а при такой организации где-то в районе десятков гигабайт исходников с доками и ресурсами уже Git можно выкидывать на мусорку, или, как минимум, подпирать его каким-нибудь repo. Но и repo уже не прокатит на масштабе в сотни гигабайт, потому что скорость работы Git становится смехотворна.

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

byko3y ★★★★
()

А есть Subversion

Дык радоваться надо, ведь мог быть perforce

DawnCaster ★★
()
Ответ на: комментарий от Irben

Работает - не трогай.

Ну если корректно сделано конечно.

XoFfiCEr ★★☆☆
()

Обнови джаву. Переведи проект на git. Внедри систему управления паролями. Какие проблемы-то? Ныть все горазды.

PS так и вижу 1600 микросервисов на всевозможных версиях джавы, дотнета, гошки, ноды и даже немного раста. Пароли в каждом хранятся по своему. Каждый запускается в своей ОС. И всё в свн монорепе.

Legioner ★★★★★
()
Последнее исправление: Legioner (всего исправлений: 4)
Ответ на: комментарий от menangen

Нет, у нас серверная Windows Vista

GP
() автор топика

Сопли смузихлёба. Если ты ищешь поддержки, то тебе её не найти. Не ной, а начни потихоньку приводить в порядок проект. Не можешь? Так и скажи: я не компетентен, прошу уволить меня по собственному желанию.

cocucka ★★★★☆
()

Ты описал практически любую ентерпрайз систему, которая живёт лет 10 и разрабатывается большим числом компаний на аутсорсе.

Чешу репу и хочу уйти назад в микросервисы на ноде.

Которые через 10 лет даже собираться не будут, а работать и тем более. А это г работает и решает корпоративные бизнес задачи и, возможно, тебя ещё переживёт.

И гита у нас нет. И не будет в ближайшие 30 лет. А есть Subversion. Где фактически нет бранчей.

это у тебя кой чего нет, а в svn всё что надо есть.

vtVitus ★★★★★
()
Ответ на: комментарий от vtVitus

Прикол в том, что порой достаточно и 5ти лет и уже не запустится. Особенно, если все зависимости не включены в проект, хотя бы как запасной вариант. У нас было такое уже многократно с новыми проектами, которые брали на переработку. Вроде коду 3-5 лет, а уже хрен, не запускается, только разве что в контейнер или того хуже в виртуалку перетаскивать прямо с продакшина все зависимости и дальше думать как это актуализировать.

А с другой стороны какое-нибудь говно мамонта из энтерпрайза на java или обоже на VB .NET вполне себе запускается с минимальными танцами на актуальных системах или хотя бы на неактуальных, но можно таки развернуть.

Увы, смузихлёбы не понимают вообще этого. А те кто их нанимает, тем выгодно, что надо каждые 5-10 лет переписывать всё нахер. Но прикол в том, что ни одну сложную систему за 5 лет не написать и не отладить. Нужно больше времени.

ixrws ★★★
()
Ответ на: комментарий от GP

А что с тегами не так? Релизный бранч конечно удобнее, его хотфиксить проще, но если цикл короткий - можно и тегами.

upcFrost ★★★★★
()
Ответ на: комментарий от ixrws

Прикол в том, что порой достаточно и 5ти лет и уже не запустится.

Для того есть всякие докеры и CI. Ну и фиксация версий зависимостей, которую адепты монореп пытаются закопать

upcFrost ★★★★★
()
Ответ на: комментарий от upcFrost

стоп, я вот и говорю, что теги лучше бранчей

GP
() автор топика
Ответ на: комментарий от upcFrost

Ну попробуй поднять ноду пятилетней давности :) Я вот в прошлом году попробовал. Оказалось, что за это время на npmjs.org поменяли 1) урлы на загрузку; 2) формат хэш-сумм. Здрасьте приехали.

Ну т.е. да, ты можешь упаковать в докер готовое собранное приложение, но reproduceability процесса сборки просто нулевая.

leave ★★★★★
()
Ответ на: комментарий от upcFrost

В теории, работает неплохо. На практике у крупного проекта часть зависимостей просто исчезает через 10 лет. То есть они физически исчезают из источников распространения.

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

И не надо говорить тут как оно должно быть. Именно так это и работает. А потому что бабки. Ни одна, даже очень крупная, контора не будет вливать в один и тот же проект одинаково гигансткий бюджет каждый код. Есть активная разработка, есть период эксплуатации. Это нормально. Есть люди, обычно очень молодые, которые просто с таким не сталкивались и они убеждены, что напилив сегодня кучу микросервисов и микрофронтендов на каких-нибудь go и ts всё будет ок вечно. Нет, будет ок пока поддерживаете. А есть ещё люди, кому выгодно, чтобы разработанный ими продукт требовал вливаний каждый год, хороших вливаний. Но прикол в том, что заказчику всё равно насрать и у него своё мнение. Он всё равно не будет выделять одинаковый бюджет. А если вы его сильно выбесите, то ещё другого исполнителя найдёт.

ixrws ★★★
()
Ответ на: комментарий от leave

Вот и придётся следующей команде брать сборку продакшина, крутить её в локальном контейнере и постепенно обновлять код. Если денег дадут:) А если не дадут, то будут править прямо в готовой сборке. Внесут в репозиторий все зависимости и будут тупо апдейтить старый код, который будет привязан к старым зависимостям навечно.

ixrws ★★★
()
Ответ на: комментарий от ixrws

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

Прям по-живому. У нас именно так и происходит с легаси проектами.

leave ★★★★★
()
Ответ на: комментарий от ixrws

Вот и придётся следующей команде брать сборку продакшина, крутить её в локальном контейнере и постепенно обновлять код

Есть у нас одна прилага для интеграции с корейским интернетом по паспорту. Написана под 2.6 питон на твистеде, дергает несколько бинарей, которые выдали корейцы. Бинари слинкованы динамически в окружении 5й шапки. Исходники самого приложения существуют в единственном экземпляре - на продакшене. Весь CI и репа были на локалхосте хипстера, который это пилил.

Потихоньку корячу в докер с LD_LIBRARY_PATH и patchelf. Девопс епта!

leave ★★★★★
()
Ответ на: комментарий от ixrws

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

+1

wandrien ★★
()
Ответ на: комментарий от leave

А у нас тонны старого кода на vb, c#, sql разных мастей, java и немного современного, но уже давно протухшего на nodejs. Всё давно протухло, всё имеет подобные вашим нюансы. Сочувствую!

ixrws ★★★
()
Ответ на: комментарий от leave

Исходники самого приложения существуют в единственном экземпляре - на продакшене. Весь CI и репа были на локалхосте хипстера, который это пилил.

Мда. Прям родное.

Достался на разработку проект, который существовал в единственной копии на продакшене. Команда, которая изначально его пилила, давно свалила в закат вместе с CI и репами. После неё проект допиливали кто во что горазд прямо на продакшене.

Документации нет. В сорцах несколько наслоений разных уровней легаси. В одних модулях прослеживается неплохая архитектура, а тут же в соседних может быть сплошая портянка на несколько тысяч строк с глобальными переменными и магическими константами.

wandrien ★★
()
Ответ на: комментарий от rupert

Не всегда, очень зависит от заказчика и конечно же бюджета.

Бывает так, что надо тупо впилить новые фичи, например современный web api в систему, которая интернет то видела только в корпоративной локалке:) И тут конечно самые соки и весь ад. Толком всё перекроить не выйдет, но латать придётся всё равно, ибо всё сломается если не латать:)

А бывает сам заказчик просит починить всё, выделяет бюджет и работать даже приятно. Ну так скажем всё относительно. Всё равно ощущение разбора конюшень остаётся:)

ixrws ★★★
()
Ответ на: комментарий от leave

Ну попробуй поднять ноду пятилетней давности

Нода пять лет назад была мягко говоря не готова для ынтерпрайза

upcFrost ★★★★★
()
Ответ на: комментарий от ixrws

Оказывается, что реально работает только продакшин, вся инфраструктура тестирования и разработки либо отключена, либо просто давно даёт ошибки

От этого надо ставить тесты overnight, с пинанием причастных в случае поломки.

upcFrost ★★★★★
()

credentianals разбросаны по всему проекту. И их примерно 1600 штук.
есть Subversion

Я не особо максималист, но тут лучше сразу уйти.
Потом всё равно уйдёшь, но уже уставший.

aidaho ★★★★★
()
Ответ на: комментарий от leave

Да это спекулятивная тема для бросания известно чем. Не набрасывайте.

XoFfiCEr ★★☆☆
()
Ответ на: комментарий от leave

Говнокод везде. Вообще везде.

Ну странно, а ведь на лоре столько мастеров совершенного кода. Посмотришь и диву даешься какие кодеры все крутые. Кто только подкладывает в шаровары непонятно.

bread
()
Последнее исправление: bread (всего исправлений: 1)
Ответ на: комментарий от rupert

Ради парочки бинарей?

Ну если все закончится прямым копирование всего лейаута в контейнер то так и сделаю, наверное. Спасибо за идею.

leave ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.