2016-10-07 7 views
2

Я искал репозитории артефактов для того, что наша команда разработчиков может использовать для хранения результатов полной сборки из нескольких проектов. Из того, что я читал, хранилища артефактов в основном используются для хранения файлов библиотеки, необходимых для сборки. Мое предположение заключается в том, что их предполагаемое использование заключается в том, чтобы разработчики и серверы сборки использовали одни и те же двоичные зависимости во время процесса сборки.Использование хранилища артефактов для хранения полных версий?

Несколько вопросов:

  • Можно ли хранить выход сборки целых проектов в хранилище артефактов (полный выпуск), место для хранения артефактов, готовых к развертыванию?

  • Это обычная практика?

  • Возможно ли иметь аналитику того, что было изменено с момента последней сборки? Пример: могу ли я увидеть, какие артефакты изменились со времени последнего выпуска?

ответ

2

Итак, короткий ответ на ваши вопросы: да, да и в основном да.

Хотя верно, что двоичные менеджеры, такие как Artifactory, используются для управления зависимостями, они также используются для размещения целых сборок. В Artifactory это можно легко достичь через Build Integration features. Если вы не используете какой-либо сервер CI, например Jenkins (например), вы можете использовать JFrog CLI, чтобы загрузить свои сборки и их соответствующие Build Info.

Кроме того, что касается аналитики, не совсем так, но в Artifactory вы можете выполнить Build Diff и увидеть изменения между сборками.

Надежда Я помог,

Эран

P.S. Я работаю для JFrog

+0

Спасибо за ответ, это всегда аккуратно получать ответы от инженеров, которые на самом деле работают на этих инструментах. – TacoMaster6000

+0

Как делаются эти построения? Является ли это продуктом интеграции CI или могут ли метаданные для сборки вручную создавать инкапсуляцию нескольких проектов? Где я работаю 'builds' - еще один термин для спринта. Каждый спринтер нескольких команд компилирует/развертывает свои двоичные файлы/артефакты, и мы интегрируем их в соответствующие серверы/проекты. Можем ли мы иметь несколько артефактов из нескольких проектов, идущих в и из нескольких мест, но сгруппированных как одна сборка? – TacoMaster6000

1

Использование Sonatype Nexus woks для вас, вы можете развернуть не только артефакты Java (например: .ear, .jar, .war файлы), вы можете развернуть любые двоичные файлы, мы используют его для хранения отчетов для Orace BI Publisher или .exe.

Возможно ли сохранить вывод сборки целых проектов в хранилище артефактов (полная версия), место для хранения артефактов, готовых к развертыванию? Да, как я уже говорил, вы можете хранить любые бинарные файлы, которые вы хотите.

Это обычная практика? Я не знаю, является ли это обычной практикой, но в моем случае Это помогло нам сохранить порядок. Просто оцените, работает ли это для вас.

Возможно ли иметь аналитику того, что было изменено с момента последней сборки? Пример: могу ли я увидеть, какие артефакты изменились со времени последнего выпуска?

Sonatype Nexus обрабатывает версию для каждого артефакта (или двоичного), чтобы вы могли хранить всю «историю» из своих развертываний, а также обрабатывать политику безопасности, например, вы не могли развернуть один и тот же двоичный файл дважды с той же версией он заставляет вас развернуть новую версию таким образом, вы можете проверить, когда артефакт изменился, дата и кто загрузил артефакт.

Вот как это выглядит:

enter image description here

+0

Интересно. Наша текущая проблема заключается в том, что мы имеем массивную систему, которая в настоящее время (в какой-то мере) вручную развернута. Это побочный продукт из многих проектов со многими различными технологиями. Нам нужен способ иметь список «что изменилось» для нашей команды по интеграции (наша текущая система очень обычна), прежде чем мы окунемся в devops. Есть ли способ проверить, что изменилось с итерационного периода? – TacoMaster6000

+0

О "Что изменилось?" вы имеете в виду в коде, не так ли? Если это точка, проверьте, что в двоичном коде это не очень хорошая идея, я настроил jenkins, используя конвейер, который создает двоичный файл, а затем развертывает его в Nexus. Как это работает? Вы делаете checkout из SVN (или git), и в конвейере вы можете видеть, действительно ли комментарии коммита и какие файлы были изменены, тогда он будет развернут в Nexus как двоичный (скомпилированный код), так что вы можете увидеть, что изменилось, если вы используете некоторые CI (как Jenkins) в вашей организации –

+0

Я имею в виду то, что изменилось в хранилище артефактов после периода спринта. Сейчас у нас есть ручной процесс интеграции, который нам нужно сохранить, пока мы не сможем полностью автоматизировать интеграцию с развертыванием. Сейчас у нас есть около 20 проектов с различными технологиями, которые все живут под одним и тем же циклом выпуска. Чтобы упростить работу нашей группы интеграции, нам нужен список, чтобы увидеть, что было изменено со времени последнего спринта, чтобы удовлетворить наши требования, пока мы работаем с DevOps. – TacoMaster6000