Следует ли использовать Git для хранения сборок непрерывной интеграции?

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

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

Существует ли согласованный стандартизированный способ управления/публикации этих временных артефактов сборки?


git continuous-integration build artifactory ivy
person Syndrome    schedule 23.01.2013    source источник
comment
Зачем тебе хранить артефакт? Сборки можно воссоздавать.   -  person Dave Newton    schedule 24.01.2013
comment
(Во всяком случае, я имею в виду git. Разве большинство серверов CI не хранят сборки в течение настраиваемого периода времени?)   -  person Dave Newton    schedule 24.01.2013
comment
Сборки можно воссоздать, но среды сборки иногда нельзя. Если вы не держите всю свою цепочку инструментов под контролем версий, нет уверенности, что вы сможете построить тот же двоичный файл по прошествии большого количества времени. Кроме того, невозможно создать точно такой же двоичный файл (встроенные временные метки приводят к разным контрольным суммам файлов). Это затрудняет доверие третьих сторон к вашему программному обеспечению или его сертификацию, если только они не создают его из исходного кода.   -  person Mark O'Connor    schedule 24.01.2013
comment
Да, использование CI-сервера возможно. Я вижу это так же, как использование каталога. Я думаю, у нас было бы дополнительное преимущество автоматической очистки переходных сборок через заданный интервал. Мммм.   -  person Syndrome    schedule 24.01.2013

Ответы (1)


arrow_upward
14
arrow_downward

Я бы не стал хранить артефакты сборки в git, а вместо этого рассмотрю совместное использование артефактов сборки либо с сервера непрерывной интеграции (CI), либо из выделенного репозитория артефактов, такого как artifactory или nexus. В общем, я считаю, что лучше избегать больших двоичных файлов во всех SCM, поскольку вы не можете их сравнивать или делать добавочные обновления, поэтому вы обнаружите, что ваш репозиторий git быстро растет, поскольку он сохраняет полную версию двоичного файла при каждом изменении.

Большинство инструментов непрерывной интеграции (например, Jenkins) могут архивировать последние X артефактов сборки или все артефакты сборки, созданные в течение последнего месяца. У них также есть плагины, которые помогают поддерживать и автоматизировать процесс продвижения сборок, которые вы считаете полезными (например, Продвижение сборки Jenkins).

Используя репозиторий артефактов или сервер CI для управления артефактами сборки, вы также обычно можете получить доступ к артефактам через API, который очень полезен, когда вы хотите автоматизировать процессы развертывания, например, вы можете делать такие вызовы, как «getLastSuccesfullBuild» и «getLastPromotedBuild( )' так далее.

person pipe-devnull    schedule 23.01.2013
comment
+1 Менеджеры репозиториев, такие как Nexus, Artifactory или Archiva, предназначены для решения этой проблемы. Ознакомьтесь с их особенностями. Мы используем Nexus Professional, который позволяет нам размещать наши выпуски и создавать рабочие процессы сертификации, где разработчики создают артефакты сборки, которые впоследствии утверждаются отделом тестирования и контроля качества перед попаданием в производственный репозиторий. - person Mark O'Connor; 24.01.2013