#deployment #build #artifactory #artifact
#развертывание #сборка #artifactory #артефакт
Вопрос:
Я искал в репозиториях артефактов что-то, что наша команда разработчиков может использовать для хранения выходных данных полных сборок из нескольких проектов. Из того, что я прочитал, репозитории артефактов в основном используются для хранения библиотечных файлов, необходимых для сборки. Я предполагаю, что их предполагаемое использование заключается в обеспечении того, чтобы разработчики и серверы сборки использовали одни и те же двоичные зависимости во время процесса сборки.
Несколько вопросов:
-
Возможно ли сохранить выходные данные сборки целых проектов в хранилище артефактов (полный выпуск), место для хранения артефактов, готовых к развертыванию?
-
Это обычная практика?
- Возможно ли иметь аналитику того, что было изменено с момента последней сборки? Пример: могу ли я увидеть, какие артефакты изменились с момента последнего выпуска?
Ответ №1:
Итак, краткий ответ на ваши вопросы: да, да и в основном да.
Хотя верно, что бинарные менеджеры, такие как Artifactory, используются для управления зависимостями, они также используются для размещения целых сборок. В Artifactory это может быть легко достигнуто с помощью функций интеграции сборки. Если вы не используете какой-либо сервер CI, такой как Jenkins (например), вы можете использовать JFrog CLI для загрузки своих сборок и соответствующей информации о сборке.
Кроме того, что касается аналитики, не совсем как таковой, но в Artifactory у вас есть возможность выполнять Build Diff и просматривать изменения между сборками.
Надеюсь, я помог,
Eran
p.s. Я работаю в JFrog
Комментарии:
1. Спасибо за ответ, всегда приятно получать ответы от инженеров, которые действительно работают над этими инструментами.
2. Как создаются эти различия в сборке? Является ли это продуктом интеграции CI или метаданные для сборки могут быть созданы вручную для инкапсуляции нескольких проектов? Где я работаю, «сборки» — это еще один термин для sprint. Каждый спринт несколько команд компилируют / развертывают свои двоичные файлы / артефакты, и мы интегрируем их на соответствующие серверы / проекты. Можем ли мы иметь несколько артефактов из нескольких проектов, отправляемых в несколько мест и из них, но группироваться как одна сборка?
Ответ №2:
Используя Sonatype Nexus woks для того, что вам нужно, вы можете развертывать не только артефакты Java (например: файлы .ear, .jar, .war). вы можете развертывать любые двоичные файлы, мы используем его для хранения отчетов для Orace BI Publisher или двоичных файлов .exe.
Возможно ли сохранить выходные данные сборки целых проектов в хранилище артефактов (полный выпуск), место для хранения артефактов, готовых к развертыванию?Да, как я уже говорил, вы можете хранить любые двоичные файлы, какие захотите.
Это обычная практика?Я не знаю, является ли это обычной практикой, но в моем случае это помогло нам сохранить порядок. Просто оцените, работает ли это для вас.
Возможно ли иметь аналитику того, что было изменено с момента последней сборки? Пример: могу ли я увидеть, какие артефакты изменились с момента последнего выпуска?
Sonatype Nexus обрабатывает версию для каждого артефакта (или двоичного файла), чтобы вы могли хранить всю «историю» ваших развертываний, а также может обрабатывать политику безопасности. например, вы не можете дважды развернуть один и тот же двоичный файл с одной и той же версией. это заставляет вас развертывать новую версию таким образом, выможно проверить, когда артефакт изменился, дату и кто загрузил артефакт.
Вот как это выглядит:
Комментарии:
1. Интересно. Наша текущая проблема заключается в том, что у нас есть массивная система, которая в настоящее время (в некоторой степени) развертывается вручную. Это побочный продукт множества проектов с множеством разных технологий. Нам нужен способ иметь список «что изменилось» для нашей группы интеграции (наша текущая система очень настраиваемая), прежде чем мы перейдем к devops. Есть ли способ проверить, что изменилось с периода итерации?
2. О том, «Что изменилось?» вы имеете в виду в коде, верно? Если это точка, убедитесь, что в двоичном файле это не очень хорошая идея, я настроил jenkins с использованием конвейера, который создает двоичный файл, а затем развертывает его в Nexus. Как это работает? Вы выполняете проверку из SVN (или git), и в конвейере вы можете увидеть фактические комментарии к фиксации и какие файлы изменились, затем это будет развернуто в Nexus как двоичный файл (скомпилированный код), так что каким-то образом вы можете увидеть, что изменилось, если вы используете некоторый CI (как Jenkins) вваша организация
3. Я имею в виду, что изменилось в репозитории артефактов после периода спринта. Прямо сейчас у нас есть ручной процесс интеграции, который нам нужно сохранить, пока мы не сможем полностью автоматизировать сборку-развертывание-интеграцию. Сейчас у нас около 20 проектов с разными технологиями, которые работают в рамках одного и того же цикла выпуска. Чтобы упростить задачу для нашей команды интеграции, нам нужен список, чтобы увидеть, что было изменено с момента последнего спринта, чтобы удовлетворить наши требования, пока мы работаем до DevOps.