А это не в pom лежит. Точнее, запретить это туда сунуть вряд ли можно, но что это конкретно не рекомендуется — вполне четко сформулированное заявление.
Конечно лежит. Тэг <repositories> никто не запрещал, и наша статистика по стиранию этого тэга автоматически в Артифактори удручает.
Плагины, в порядке? Я с 2005 года на мавене, и никогда не указывал порядок. Так что это как минимум перебор. Вообще, в реальных проектах у меня редко бывает больше двух плагинов.
Это, мягко говоря, лукавство. В тэге <phase> указывается, в какой фазе плагин запускать. Более того, само перечисление плагинов это уже детали сборки, которым нечего делать в документе метадаты артифакта.
Генеришь — это значит, что ты должен фактически собрать проект.
Эта фраза как раз показатель, что разницу между скриптом и метадатой я плохо объяснил. Из метадаты ничего нельзя "собрать", потому что там нехватает деталей о порядке и способе сборки. И нехватает там этих деталей, потому-что им там не место.
иначе откуда гарантия, что метаданные актуальны, и вообще там есть?
Ну, гарантия, например, из логики генерации этой метадаты из скрипта. Если зависимости достаточны для того, чтобы сборка в Грейдле прошла, и эти зависимости попадают в сгенерированный pom.xml, очевидно, эта метадата верна. Если это не так, Грейдлу надо чинить баги.
На счет обработки, я не очень понял, к чему этот параграф вообще. Тебе для чего-то нужны все подробности о процессе сборки? Прекрасно, они есть в source control, рядом с сорцами (которые тоже нужны для сборки). Просто эти подробности не являются метаданными артифакта, и путать эти 2 понятия, как это исторически делал Мавен — нехорошо. Рад, что наконец до них дошло.
откуда качать зависимости — это часть билда, не metadata. Какие плагины в каком порядке запускать — это часть билда, не metadata.
Metadata это то, что выдает в pom, например gradle – id, url, cms, authors, description, зависимости. Всё.
Как строить (не важно, в коде это описано, или в XML) – это часть скрипта.
И в Gradle с метаднными, конечно, намного лучше. Ты просто генеришь их в том формате, в котором захочешь — pom.xml, ivy.xml, и публицируешь сместе с артифактами. Полное разделение от скрипта, как и должно быть.
Меня попросили сравнить с Artifactory, так что я прям тут и напишу.
управление доступом на основе ролей
Есть.
пользовательский веб-интерфейс для просмотра репозиториев, поиска по ним, управления проектами;
Есть.
аудит всех операций;
Есть.
REST API для управления.
Есть.
Сканирование уязвимостей.
Есть, причем не только os level, но и вся аппликативная часть, вне зависимости от того, на чем написана.
Подпись образов.
Из коробки нет, но нет никаких проблем вызывать notary из beforeDownload user plugin–a, если надо.
Теперь, о главном. Никто, и вы в том числе не используете в организации только докер. В контейнеры вы заворачиваете код, при написании которого используется дофига всего, всякие джавы, питоны, сишарпы, гошечки, и даже, возможно, джаваскрипт. Весь этот зоопарк тоже требует управиления зависимостями, и если вы смотрите на Харбор, то даже энтерпрайзного уровня. Вы, конечно, можете, притащить для каждого элемента стэка свою балалайку, и даже, допустим, она будет отлично работать, но как вы сможете коррелировать между зависимостями и артифактами аппликативного уровня, образами Докера и чартами Хелма? Как вы сможете сказать "мне в продакшн нужен последний чарт, в образе которого нет никаких уязвимостей, и джавовый код которого прошёл все проверки в своем джавовом пайплайне"?
Ну, и пожалуй спрошу у вас вот еще что, неужели вам бы не хотелось иметь более строгие границы между этапами пайплайна для контейнеров, чем просто директории внутри regisry? Например, отдельные registry для dev и prod? Если да, то может не стоит ставить по registry для каждой среды, а вместо этого пользоваться тулом, в котором можно сделать сколько хочешь таких registry, опять же с promotion и связью между ними?
Ну и напоследок, я не знаю, как в Харборе с такими enterprise фичами как high availibilty, replication и подключаемым любым storage? Потому что это обязательные штуки для того, чтобы называться "registry-сервером корпоративного класса".
Во-первых, я любя :)
Во-вторых, человеки ленивые. Говоришь кошмарно-неправильный термин, и сразу сэкономил пару предложений объяснений, кого ты имел ввиду.
В целом, у нас с тобой полное согласие по вопросу терминологии, конечно.
Если подумать, то смотреть стримы ровно ничем не отличается от "смотреть спорт", нет?
Вы начинаете о чем-то догадываться!
Прекрасный ресурс, я считаю. "Утащено!"
Конечно лежит. Тэг
<repositories>никто не запрещал, и наша статистика по стиранию этого тэга автоматически в Артифактори удручает.Это, мягко говоря, лукавство. В тэге
<phase>указывается, в какой фазе плагин запускать. Более того, само перечисление плагинов это уже детали сборки, которым нечего делать в документе метадаты артифакта.Эта фраза как раз показатель, что разницу между скриптом и метадатой я плохо объяснил. Из метадаты ничего нельзя "собрать", потому что там нехватает деталей о порядке и способе сборки. И нехватает там этих деталей, потому-что им там не место.
Ну, гарантия, например, из логики генерации этой метадаты из скрипта. Если зависимости достаточны для того, чтобы сборка в Грейдле прошла, и эти зависимости попадают в сгенерированный pom.xml, очевидно, эта метадата верна. Если это не так, Грейдлу надо чинить баги.
На счет обработки, я не очень понял, к чему этот параграф вообще. Тебе для чего-то нужны все подробности о процессе сборки? Прекрасно, они есть в source control, рядом с сорцами (которые тоже нужны для сборки). Просто эти подробности не являются метаданными артифакта, и путать эти 2 понятия, как это исторически делал Мавен — нехорошо. Рад, что наконец до них дошло.
Ну зачем же так? Простейший Artifactory решает же.
Our job here is done.
SUUUQAH!!! Чур меня, чур!
Ну кто же ожидает хэпиенд у трагедии?
Они вообще не собирали никаких бинарников. Node.js жи, написали код, прогнали тесты на CI, и вперёд, исходники в облако на прод.
Если бы вы знали, сколько маленьких стартапов так и делают. Всегда же можно откатиться на предыдущий комммит!
Не было никакого Docker registry. Artifactory появился только на следующем этапе же.
откуда качать зависимости — это часть билда, не metadata. Какие плагины в каком порядке запускать — это часть билда, не metadata.
Metadata это то, что выдает в pom, например gradle – id, url, cms, authors, description, зависимости. Всё.
Как строить (не важно, в коде это описано, или в XML) – это часть скрипта.
И в Gradle с метаднными, конечно, намного лучше. Ты просто генеришь их в том формате, в котором захочешь — pom.xml, ivy.xml, и публицируешь сместе с артифактами. Полное разделение от скрипта, как и должно быть.
НАКОНЕЦ-ТО!!! Наконец-то до них дошло, что build script и artifact metadata это разные артифакты и смешивать их нельзя!!!
Фух. Самое время закурить сигарету "после". Я это слышал раза 3, но всё равно, насладился как в первый раз.
В опросе нет опции "Я спикер, если я не пойду, мне 23derevo выпишет звиздюлей".
Меня попросили сравнить с Artifactory, так что я прям тут и напишу.
Есть.
Есть.
Есть.
Есть.
Есть, причем не только os level, но и вся аппликативная часть, вне зависимости от того, на чем написана.
Из коробки нет, но нет никаких проблем вызывать notary из beforeDownload user plugin–a, если надо.
Теперь, о главном. Никто, и вы в том числе не используете в организации только докер. В контейнеры вы заворачиваете код, при написании которого используется дофига всего, всякие джавы, питоны, сишарпы, гошечки, и даже, возможно, джаваскрипт. Весь этот зоопарк тоже требует управиления зависимостями, и если вы смотрите на Харбор, то даже энтерпрайзного уровня. Вы, конечно, можете, притащить для каждого элемента стэка свою балалайку, и даже, допустим, она будет отлично работать, но как вы сможете коррелировать между зависимостями и артифактами аппликативного уровня, образами Докера и чартами Хелма? Как вы сможете сказать "мне в продакшн нужен последний чарт, в образе которого нет никаких уязвимостей, и джавовый код которого прошёл все проверки в своем джавовом пайплайне"?
Ну, и пожалуй спрошу у вас вот еще что, неужели вам бы не хотелось иметь более строгие границы между этапами пайплайна для контейнеров, чем просто директории внутри regisry? Например, отдельные registry для dev и prod? Если да, то может не стоит ставить по registry для каждой среды, а вместо этого пользоваться тулом, в котором можно сделать сколько хочешь таких registry, опять же с promotion и связью между ними?
Ну и напоследок, я не знаю, как в Харборе с такими enterprise фичами как high availibilty, replication и подключаемым любым storage? Потому что это обязательные штуки для того, чтобы называться "registry-сервером корпоративного класса".
Смотря кого, ты имеешь ввиду. Часто DevOps-ом называют SRE, часто tooling teams.
Во-первых, я любя :)
Во-вторых, человеки ленивые. Говоришь кошмарно-неправильный термин, и сразу сэкономил пару предложений объяснений, кого ты имел ввиду.
В целом, у нас с тобой полное согласие по вопросу терминологии, конечно.
Сейчас придет bsideup и будет порицать нас за "DevOps инженеров". Вычитывали-вычитавали, да не вычитали.
Обнимашки!
Гуглить event gamification.
Неистово орал всю дорогу.