Комментарии 15
Вы же не руками обновляли сервисы? OpenRewrite же?
Зачем вы оправдываетесь в конце? Вы как профессионалы сами решаете, когда, как и зачем апгрейдить ПО. Кому интересна аргументация - пусть релиз ноутсы читает.
Если долго не обновлять бэкэнд, то уязвимости копятся, их количество начинает исчисляться сотнями
В экосистеме джавы сегодня много делается не столько ради устранения CVE, сколько ради оптимизации. Java 8 и грядущая Java 24 - разные вещи в плане перфоманса. То же самое хибер сегодня и хибер времен 8 джавы.
Посмотрите на это глазами бизнеса. Вы тратите несколько месяцев работы нескольких ваших инженеров. В конце вы с высокой вероятностью получите еще и ряд проблем на проде. Все это стоит денег.
Что вы получаете взамен? Если улучшение перформанса, то вам необходимо понимать, сколько именно. Плюс пять процентов? Десять? Или вообще минус? Вам следует это посчитать и понять, стоит ли оно того. Может дешевле просто добавить сервер в кластер?
Аргументация о том, что в системе устраняются проблемы безопасности, универсальна и понятна каждому.
Посмотрите на это глазами бизнеса. Вы тратите несколько месяцев работы нескольких ваших инженеров. В конце вы с высокой вероятностью получите еще и ряд проблем на проде. Все это стоит денег.
С точки зрения бизнеса любая инженерная деятельность это какая-то мутная возня, которая стоит денег и иногда приводит к проблемам на проде. Система может навернуться как после "ненужного" апгрейда зависимости, так и после "нужного" внедрения фичи. После фичи даже гораздо вероятнее все распердолить. С т.з. пресловутого бизнеса - никакой разницы.
Поэтому не хватало еще себе голову забивать, что там бизнес думает. А тем более оправдываться. Он мне платит, чтобы наблюдать некий полезный эффект - вопросов ноль, эффект будет. А уж каким образом он будет - не его, бизнеса, дело.
Глазами бизнеса как раз таки все понятно. Приходит клиент, запрашивает аудит. Смотрит результаты и говорит, что он не будет заключать договор по причине того, что ваш продукт дырявый и с кучей уязвимостей.
есть же netty
По моему опыту обновление бэкэнда - это всегда долго, сложно и сопряжено с большим количеством проблем, в том числе иногда и для бизнеса (в худшем случае).
Я в прошлом году переводил проект меньше раз в 7 (~300 Котлин файлов), но порядка на 2-3 быстрее:
Для перехода я:
очевидным образом, обновил версии
заменой по проекту поправил javax.* -> jakarta.*
Поменял com.github.tomakehurst:wiremock-jre8:2.35.0 -> com.github.tomakehurst:wiremock-jre8-standalone:2.35.0. Без этого были проблемы со спекой сервлетов, что ли
В конфиге Spring Security заменой по файлу поправил antMatchers -> requestMatchers
Руками поудалял ConstructorBinding
Больше всего времени ушло на то, чтобы реанимировать вытягивание доков к эндпоинтам в сваггере из котлин доков. Для этого пришлось руками добавить зависимость runtimeOnly("com.github.therapi:therapi-runtime-javadoc:0.15.0"), а допетрить до того, что этот джарник пропал из зависимостей (без ошибок) пришлось самостоятельно
всё. Все 100+ тестов (преимущественно пользовательских/внешних/функциональных/е2е) прошли, приложение благополучно задеплоилось на тестовый стенд. И потом обошлось без факапов в проде
Всё это я сделал часа за два грустным вечером 5-ого января:)
Возможно секрет в том, что проект у меня был на Spring Data JDBC:)
А теперь представьте проект на 3+ млн. строк кода и 100+ разработчиков которые за 15+ лет несколько раз поменялись и трижды переписали компоненты с разной степенью успеха и с соответствущими технологическими наслоениями.
К такому проекту я и на пушечный выстрел не подойду:)
Но если проект на 3M строк и 100 разработчиков попилен на 30 сервисов по 100К кода и покрыт качественными тестами - каждый сервис мигрируется также в пределах рабочего дня. Тот же проект, когда он был уже на 50К строк Котлин кода (и я его уже этом размере попилил на два сервиса) на минорные версии обновлялся за минуты.
Чем больше проект, ИМХО, тем чаще нужно делать более минорные обновления, иначе очень быстро они накапливаются в непреодолимый ком.
Перешли сразу с 2.7 на 3.3? Если так, то почему решили пропустить 3.0?
Если liquibase при выполнении миграций увидит, что у одного из старых changelog’ов чексумма отличается от той, что записана в базе, то он упадёт с ошибкой.
в liquibase уже много лет присутствует возможность писать миграции идемпотентно, отсюда удаление записей о миграциях никак не влияет на конечный результат их многократного применения
Как мы обновляли продакшн до Spring Boot 3