Как сохранить выпущенные двоичные файлы под контролем версий?

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

Два варианта:

а) не надо Просто убедитесь, что у вас есть воспроизводимые детерминированные сборки, т. Е. Сборка одной и той же ревизии системы контроля версий с одинаковой конфигурацией всегда дает один и тот же двоичный файл.

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

В любом случае, бинарные файлы и другие выходные данные сборки не находятся под контролем исходного кода по многим причинам.

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

Смотрите, например, репозитории Maven в качестве репозитория для архивирования / публикации / предложения выпусков и других двоичных файлов (например, таких как документация)

Просто вставьте их. С этим проблем нет, если только вы не используете git (который плохо объединяет двоичные файлы, так что вам придется управлять ими самостоятельно), или вы делаете это слишком много раз (только когда это происходит готово к отправке, не каждый раз, когда вы его строите).

Большинство дельта-двоичных файлов SCM довольно хорошо, мы использовали для размещения в нашей SVN 2-мегабайтный ресурсный ресурс, и каждый раз он бы составлял несколько килобайт.

Я слышал много аргументов, что SCM для источника, а не для двоичных файлов, но это явно неверно, если учесть, что большинство программного обеспечения состоит из изображений, даже если они просто файлы значков. Это двоичные файлы, но они являются частью источника, так что вставьте их и не будьте настолько догматичными. Я также слышал, что вы можете просто перестроить двоичный файл, когда это необходимо, часто это так, но это может быть огромной тратой времени на старые системы, которые больше не поддерживаются. Если вам нужно заново создать систему только с более старыми пакетами обновлений или исправлениями, чтобы соответствовать системе, которая использовалась для сборки двоичного файла 3 года назад, вы будете рады, что добавили корзину в свой SCM.

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

Я не держу исполняемые файлы под контролем версий. Вместо этого я публикую их в четко определенном месте, чтобы другие инструменты и проверять и использовать их. Я много работаю на Java, поэтому я публикую Jars в локальных репозиториях Maven. Однако я не использую эти инструменты, чтобы отслеживать, что изменилось в каждой версии. В конце концов, они являются двоичными файлами, и не так много нужно отслеживать, кроме количества файлов.

Чтобы отслеживать изменения между выпусками, я бы помечал или маркировал выпуски в моей системе управления версиями номером версии выпуска. Но это действительно только для отслеживания исходных файлов, а не двоичных файлов. Двоичные файлы являются артефактами сборки и не должны находиться под контролем версий.

Лучшее решение состоит в том, чтобы эксклюзивно использовать вашу систему CI для всех существенных для организации сборок (выпусков, кандидатов на выпуск и т. Д.).

Это систематически связывает освобожденные двоичные файлы с содержимым репозитория без необходимости фактически сохранять двоичные файлы в репозитории.

Например, если вы используете SVN, используйте схему организации филиала; Выполняйте всю повседневную разработку в / trunk и создайте тег / для каждого выпуска, как только он будет готов.

Сконфигурируйте свою систему CI для сборки как из тегов, так и из транка, и заставьте ее записывать выходные данные в сетевой каталог, структура которого отражает структуру верхнего уровня репо:

• / Строит / багажник / [об] [дата] [build_id] /
• / Сборки / теги / release_0_1_3beta4 / [об] [дата] [build_id] /

Система сборки должна обрабатывать каталог / builds / trunk / как кольцевой буфер, сохраняя последние n сборок, удаляя старые сборки по мере необходимости.

/ Сборки / теги / каталог, с другой стороны, является постоянным магазином. Сами артефакты сборки хранятся в каталогах с именами, сгенерированными по следующей схеме:

• [Об] [дата] [build_id]

где [rev] - это идентификатор версии SVN, [date] - это дата в формате ГГГГММДД , а [build_id] - это уникальный трехзначный счетчик, который увеличивается от первой сборки и делает каждый каталог сборки уникальным.

Процесс, описанный выше, дает вам следующие преимущества:

1. Артефакты сборки систематически связаны с источником, который их сгенерировал, так что вы легко можете найти источник для конкретного артефакта сборки (и наоборот).

2. Это формирует основу для дальнейшей автоматизации выпуска. Например, автоматическое создание документов выпуска и т. Д.