Я понимаю, что во время разработки сборку артефактов помещают в репозиторий снимков.

Когда продукт должен перейти в QA для тестирования, удалите команды из хранилища моментальных снимков? Или они выполняют полную сборку, развертывают в репозиторий выпуска и затем отдают ее QA?

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

Ответы

Ответ 1

Мнения разные, вот мой подход:

Снимки для Dev

Обычно используется для сборки "отбрасывания". Я публикую их с моего сервера CI, вызванного изменениями, внесенными в исходный код. Цель создания моментального снимка - поделиться последним испытанным артефактом из определенной команды. Это важно, поскольку команды могут делиться барабанами между собой.

Этот подход намного более стабилен, чем наш предыдущий подход к обмену исходным кодом (постоянные проблемы с огнем, когда другая команда совершает то, что не удается их построить.... и, в добавок, все elses).

Очистка снимков

Я использую Nexus для управления моим репозиторием, у него есть запланированная задача, которая может быть настроена на периодическую очистку репозитория моментальных снимков. Я бы предположил, что Artifactory имеет аналогичную функциональность.

Выбранные кандидаты для QA

Я рассматриваю QA как полноразмерный выпуск для клиента. Вот почему я предпочитаю термин "кандидат на выпуск".

Ключевое различие между сборкой-кандидатом-релизом и моментальным снимком заключается в том, что исходный код "помечен" или "помечен" (в зависимости от вашей терминологии системы SCM). То, что вы делаете, - это рисование линии на песке, из которой вы можете удобно создать двоичный файл по требованию.

Nexus professional имеет промежуточный пакет, который позволяет разработчику вырезать новую версию и удерживать ее во временном "промежуточном хранилище". Очевидно, что некоторые выпуски не пройдут тестирование, и в этом случае они будут удалены. другие либо продвигаются в следующую группу в цепочке, либо публикуются в общественном месте.

Существует несколько способов реализации этой "рекламной модели" управления выпуском.

Управление версиями версий

Я использую следующее соглашение о нумерации для своих выпусков.

<major number>.<minor number>.<patch number>.<build number>

Example:
1.0.0.24

(Для более мелких/более простых проектов я могу изменить соглашение и удалить номер патча).

Ivy имеет чудесно полезную buildnumber задачу для управления добавочным номером сборки на основе того, что уже было опубликовано в вашем репозитории.

<property name="release.candidate" value="1.0.0"/>
..
<ivy:buildnumber organisation="${ivy.organisation}" module="${ivy.module}" revision="${release.candidate}"/>
..
<echo message="Release revision: ${ivy.new.revision}"/>