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

14

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

linquize
источник
Что вы подразумеваете под «отслеживать, какие вещи изменились»? Какие атрибуты исполняемых файлов вы (или хотите) отслеживать? Это кажется странным, поэтому мне любопытно.
Джереми Хейлер
например, между v1.0.0 и v1.0.1 изменяется только ABC.exe, а зависимость DEF.dll остается неизменной
linquize
1
Как вы определяете это, глядя на двоичные файлы?
Джереми Хейлер
diff старая и новая версия того же файла
linquize

Ответы:

21

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

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

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

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

tdammers
источник
7
а) часто невозможно, конечно. blogs.msdn.com/b/ericlippert/archive/2012/05/31/…
jk.
@jk: хорошая ссылка. Я предполагаю, что исходный код и все входные файлы для этапа сборки полностью под управлением исходного кода (и с установленной верной версией компилятора) могут быть "достаточно детерминированными" во многих реальных сценариях (и, конечно, не достаточными в других). ). Зависит от случая, насколько важно иметь воспроизводимые двоичные файлы побитно.
Док Браун
10

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

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

mhaller
источник
конкретная версия выпущенного исходного файла также не должна меняться со временем. SCM - это отличное место для размещения поставляемого двоичного файла, вы просто храните его вместе с исходными файлами, использованными для его сборки.
gbjbaanb
2
gbjbaanb, SCM расшифровывается как «Управление исходным кодом». Это должно дать любому намек на то, что эти системы предназначены не для хранения двоичных файлов, а для исходного кода. Если вы все еще хотите хранить двоичные файлы, продолжайте. Я не буду
mhaller
4
SCM расшифровывается как «Software Control Management», но хорошая попытка. «исходный код» часто представляет собой не просто текстовые файлы, но изображения, документы, диаграммы и т. д.
gbjbaanb
Обычно «Управление конфигурацией программного обеспечения». Я никогда не слышал об «управлении программным обеспечением».
Джеймс Маклеод
7

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

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

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

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

gbjbaanb
источник
1
@ MarnenLaibow-Koser вы, очевидно, не работали в отрасли долго. Среды построения со временем меняются, поэтому, несмотря на то, что вы можете перестроить старую, скорее всего, вам придется потратить дни на воссоздание среды с правильными старыми инструментами и SDK. Который я надеюсь, что вы версировали ....
gbjbaanb
1
Я полагаю, что вы сможете создать старый двоичный файл VC6, скомпилированный на компьютере с XP, используя старый SDK, который Microsoft больше не считает нужным выпустить. Если кто-то запрашивает этот двоичный файл, просто взять его из того же места, где хранится все остальное. Стоимость управления огромна по сравнению с болью необходимости восстановления, а стоимость хранения с источником незначительна. Я был там (с приложением VB6, созданным с помощью стороннего элемента управления, когда клиент сообщил об ошибке - получить двоичный файл и запустить его было намного проще, чем восстановить его, что оказалось невозможным)
gbjbaanb
1
@gjbaanb Я также признаю, что вы находитесь в другой ситуации от меня по-другому: все мои внешние зависимости являются OSS, поэтому они не могут исчезнуть только потому, что какая-то компания больше не считает целесообразным их выпуск.
Марнен Лайбоу-Козер
1
Суть в том , что СДМ может хранить все, так что нет никакой необходимости , чтобы не хранить двоичный файл отдельно от своего источника. Это удобно и легко и гарантирует, что вы знаете, что то, что лет спустя. Там нет недостатков в этом. Любой данный релиз сам по себе синхронизируется только с одним конкретным исходным коммитом. Я не вижу проблемы, за исключением того, что некоторые люди думают, что SCM означает только текст исходного кода. Нет, используйте это, чтобы хранить почти все (иногда включая инструменты для сборки или библиотеки, если они не огромные), жизнь становится намного проще.
gbjbaanb
1
@gjbaanb И я хочу сказать, что ты ошибаешься по этому поводу. :) Конечно, VCS могут хранить все, но они плохо настроены для хранения файлов, которые живут только для одного коммита (в конце концов, вы не хотите, чтобы ваша сборка r500 в репо на r550; это будет просто сбивать с толку) , Основная проблема с хранением артефактов сборки в репо заключается не в том, что они являются двоичными , а в том, что они являются производными данными и будут не синхронизированы с их источником в том же репо. Те же аргументы, которые я использую, будут применяться к сгенерированным текстовым файлам.
Марнен Лайбоу-Козер
5

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

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

Джереми Хейлер
источник
1

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

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

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

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

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

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

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

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

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

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

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

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

Уильям Пейн
источник