Comments 6
Например, «добавить .nnnnnn к формату времени в файле log4j.conf». Как это конкретно описано?
У нас масштаб меньше, я пишу скрипты на bash, которые обходят все репозитории, менят что-то в файлах, и коммитят.
Скрипты тоже вариант.
А java у нас используется по нескольким причинам:
1) весь остальной код на java, все разработчики в компании ее знают, т.е. поддерживать сможет каждый
2) modernizer выглядит как обычная библиотека и имеет такую же сборку и релизный цикл как библиотека, что тоже удобно в поддержке.
Доклад очень интересный, но жалко что часть про патчи действительно была опущена. Очень хотелось бы технических подробностей, как это делали: свелось ли это к условному наивному патч файлу (да, который можно автоматически применить гитом) за счет обозначенной унификации в сервисах или все же изменение представляет собой более сложный структурный поиск по коду и его модификацию.
Выглядит что эта часть содержат наибольшую "добавленную стоимость" по сравнению с распространенными системами типа dependabot/renovate.
Патчи выходят простыми, за счет унификации, Вы правы.
Уточню, что сначала происходит clone репозитория. Т.е. modernizer получает доступ к коду в директории, указанной при clone.
А затем уже отрабатывает код на java.
Например, если говорить о кейсе из доклада (этакий псевдокод для наглядности):
1) найдем файл:
Path log4jConfig = resolve(log4j.xml);2) прочитаем:
List content = Files.readAllLines(log4jConfig);
3) найдем нужную строку и сделаем в ней замену:
lineOfContent.replace("HH:mm:ss", "HH:mm:ss.nnnnnnnnn");Понятно, спасибо большое! Было бы круто иметь что-то подобное в виде опен сорс проекта, чтобы не переизобретать велоспеды заново, но это так — мечты :).
Наверное, последний вопрос — реализацию отслеживания зависмостей вы тоже делали силами modernizer'а? Если да, то какие плюсы для себя видели по сравнению с тем же renovate который можно on-premise развернуть (ну кроме опять же унификации инструмента хоть и ценой поддержки своей собственной реализации)?
Основные причины:
1) у нас уже есть modernizer :) Добавлять пусть и небольшую поддержку второго инструмента не хочется.
2) важнейшая часть modernizer — создание задач в jira. Удобно, что одним инструментом покрывается весь цикл внесения массовых изменений.
3) возможность кастомизировать modernizer и добавлять нужную именно нам функциональность.
Внести массовые изменения в микросервисы, автоматизировать код-ревью и сберечь нервы команде