Комментарии 7
Не так давно слушал доклад на такую же тему. Не проникся.
Какой смысл мониторить все зависимости эвридэй? Ведь новый релиз и так не пойдет, если SAST провалится и тогда придется идти и апать зависимости.
Опять же автоматически обновить зависимости можно, но не сломает ли это проект? Встречал лично спецэффекты при переходи на новые версии, причем они не то чтобы были очевидными. Конечно, если проект покрыт тестами вдоль и поперек, то скорей всего такая ошибка выявится, но у всех ли хорошо с тестами?
И что же получается, если в проекте скажем пару сотен зависимостей, получается нужно выкатывать новый релиз через день, т.к. что-то где-то да обновится. При этом новая функциональность не добавляется, но риск словить непредвиденный баг и сломать сервис присутствует. Ну и конечно этот подход не годится для организаций, где релизный цикл хоть как-то регламентирован, и просто так катить обновление ради обновления не получится.
Опять же автоматически обновить зависимости можно, но не сломает ли это проект?
Сломает. Обязательно сломает. Если не сразу, то потом.
но у всех ли хорошо с тестами?
У кого плохо с тестами - тому renovate противопоказан.
И что же получается, если в проекте скажем пару сотен зависимостей, получается нужно выкатывать новый релиз через день, т.к. что-то где-то да обновится.
Можно и так конечно. А можно придерживаться своего обычного графика релизов.
При этом новая функциональность не добавляется, но риск словить непредвиденный баг и сломать сервис присутствует.
Проекты в конце своего жизненного цикла, всё ещё стоящие на поддержке, именно так и поддерживаются обычно. Регулярных обновлений требуют как минимум tzdata, ca сертификаты (характерно для проектов на java, но и на других языках тоже достаточно видел) и версия юникода/ICU.
Новая функциональность тоже может приехать. Например, поддержка очередной новой версии TLS.
Ну и конечно этот подход не годится для организаций, где релизный цикл хоть как-то регламентирован, и просто так катить обновление ради обновления не получится.
Так пусть катят согласно своему регламенту, а не при каждом обновлении зависимостей.
Мне вот никогда было непонятно.
- смотрите чуваки, классная штука, все зависимости ап-ту-дейт, с красивыми пул/мердж реквестами, возможностью гибкой настройки что, где, куда и когда. экономит кучу времени на рутинных задачах.
- ой, чота нет, у нас тестов нет и вдруг оно упадет
- :фейспалм:
Я лично все время встречаю спецэфекты от программистов и не обновленных во время библиотек.
Инструмент очень мощен и удобен. На мой вкус, приятнее депенданси бота, хотя и в нем встречаются странности.
>RENOVATE_TOKEN: Это токен c scope read_user, api, and
write_repository, который предоставляет доступ к вашему репозиторию и
позволяет Renovate автоматически обновлять зависимости.
Я правильно понял, что предлагается дать какому-то внешнему коду доступ к своему приватному репозиторию?
Спасибо за статью, обожаю этот инструмент. Особенно нравится их фича с automerge.
Еще создал инструмент для контроля устаревания зависимостей: https://github.com/blablatdinov/deltaver, можно встроить в пайплайн и увидеть упавший билд из-за сильного отставания. К сожалению, не во всех компаниях есть self-hosted инстанс renovate
Автоматическое обновление зависимостей в GitLab-проектах с помощью Renovate