Сбер заменил Sonatype Nexus на собственный Artifactory с бесшовной миграцией и откатом

Источник
Миграция с Sonatype Nexus: как мы переписали код, сломали API и всё равно достигли цели

Администраторы репозиториев в Сбере столкнулись с критической проблемой: обновление версии Sonatype Nexus до 3.77+ привело к жестким лимитам на количество компонентов и запросов, что заблокировало работу разработчиков. На одном инстансе системы находилось более 10 миллионов компонентов, что сделало невозможным переход на новую версию без остановки разработки. Для решения этой задачи команда Platform V Works::Artifactory, возглавляемая Кириллом Быковым, заменила иностранный Nexus на собственный продукт, основанный на форке оригинального кода.

Ключевым условием миграции стала бесшовность процесса: разработчики не должны были замечать изменений, а команды DevOps — тратить ресурсы на перенос терабайтов данных. Реализована стратегия эволюции, при которой Artifactory запущен на той же базе данных и дисках, что и старый Nexus, без остановки сервисов. Это позволило сохранить все URL, команды и плагины CI/CD. Важнейшим аспектом стала возможность мгновенного отката как на старую версию Nexus 3.76, так и между версиями собственного продукта с помощью подготовленных SQL-скриптов, которые удаляют новые индексы и записи о миграциях.

В ходе разработки возник инцидент, связанный с нарушением обратной совместимости API. Из-за следования внутреннему стандарту Сбера, требующему возврата статуса 201 Created вместо 200 OK при создании ресурсов, клиентский код перестал корректно парсить ответы, что привело к падению системы. Команда отменила изменение, вернув старый формат ответа, и приняла решение поддерживать версию v1 API для полной совместимости, создавая новые версии (v2) только для улучшения функционала. Это подтвердило, что даже соблюдение стандартов не должно ломать существующие интеграции.

Миграция завершилась полным переводом всех инстансов в банке на новый продукт. Статистика показывает масштаб перехода: более 15 тысяч проектов, 56 миллионов артефактов и объем данных 2,3 Пб при поддержке около 500 тысяч пользователей. Производительность системы не только сохранилась, но и была улучшена за счет перехода на Java 17 и Z Garbage Collector. Опыт бесшовной замены репозитория был успешно применен и за пределами Сбера в крупных страховых и финансовых компаниях, подтвердив эффективность подхода к управлению инфраструктурой артефактов.

Текст подготовлен нейросетью Loople по материалам источника.

Читайте также

Похожие новости

Рост команды не всегда ускоряет выпуск фич: как архитектурная связность замедляет разработку

Один день на прямой SQL или три на разделение слоёв? Разбираем связность кода, адаптеры и технический долг: как сократить объём будущих пра…

Поиск по Loople

Назад