Как по-разному используются репозитории снимков и выпусков? - PullRequest
Новая
       56

Как по-разному используются репозитории снимков и выпусков?

14 голосов
/ 10 декабря 2011

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

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

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

1 Ответ

18 голосов
/ 10 декабря 2011

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

Снимки для Dev

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

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

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

Я использую 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}"/>

Свойство release.candidate обычно хранится в файле свойств под управлением версиями. Что мне действительно нравится в этом решении, так это то, что оно обеспечивает параллельное управление филиалами (см. Ответ на на этот вопрос ).

...