Двоичные файлы в системе контроля версий

При разработке для встраиваемых устройств и других странных миров весьма вероятно, что ваш процесс сборки будет включать несколько проприетарных двоичных файлов, использующих очень специфические их версии. Итак, вопрос в том, являются ли они частью вашего контроля версий? В моих офисах действует правило «проверка из исходного кода включает в себя все необходимое для компиляции кода», и это привело к серьезным спорам.

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

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

Пример: для работы со встроенными прошивками у вас обычно будет полный набор инструментов: либо собственный компилятор, который стоит больших денег, либо какая-то версия gcc. Для того, чтобы получить исполняемый файл доставки, вам нужен как набор инструментов, так и исходный код.

Проверка цепочек инструментов в контроле версий - это боль, утилиты diff ужасны (если вообще), но альтернативы нет. Если вы хотите, чтобы цепочка инструментов была сохранена для парня, который через 5 лет будет смотреть на ваш код, чтобы выяснить, что он делает, то у вас нет выбора: вы ДОЛЖНЫ также иметь цепочку инструментов под контролем версий.

За эти годы я обнаружил, что самый простой способ сделать это - создать ZIP-образ или ISO-образ установочного компакт-диска и зарегистрировать его. В комментарии для регистрации должен быть указан номер версии конкретного производителя для набора инструментов. Если gcc или аналогичный, то соберите все, что вы используете, в большой ZIP и сделайте то же самое.

Самый крайний случай, который я сделал, - это Windows XP Embedded, где «набор инструментов» - это работающая виртуальная машина Windows XP, которая включала (тогда) SQL Server и стек файлов конфигурации, а также сотни и сотни файлов исправлений. Установка всего лота и его обновление занимали около 2-3 дней. Сохранение этого для потомков означало проверку ВСЕХ ВМ в системе контроля версий. Поскольку виртуальный диск был составлен из образов размером 6 x 2 ГБ, он на самом деле работал достаточно хорошо. Звучит слишком хорошо, но это очень облегчило жизнь человеку, который пришел за мной и вынужден был им пользоваться - 5 лет спустя.

Резюме: Контроль версий - это инструмент. Используйте его, чтобы быть эффективным, не зацикливайтесь на таких вещах, как значение слов, и не называйте это «контролем над источником», потому что это больше, чем это.

Нил Форд утверждает в «Продуктивном программисте», что вы должны держать двоичные файлы в системе контроля версий:

Зачем хранить двоичные файлы? Проекты сегодня зависят от множества внешних инструментов и библиотек. Допустим, вы используете одну из популярных платформ журналирования (например, Log4J или Log4Net). Если вы не собираете двоичные файлы для этой библиотеки журналов как часть процесса сборки, вы должны держать ее под контролем версий. Это позволяет вам продолжать сборку программного обеспечения, даже если рассматриваемая среда или библиотека исчезают (или, что более вероятно, вносит существенное изменение в новую версию). Всегда держите всю вселенную, необходимую для сборки вашего программного обеспечения, в управлении версиями(минус операционная система, и даже это возможно при виртуализации; см. «Использование виртуализации» далее в этой главе). Вы можете оптимизировать сохранение двоичных файлов, сохраняя их как в системе контроля версий, так и на общем сетевом диске. Таким образом, вам не нужно иметь дело с ними ежечасно, но они сохраняются на тот случай, если вам понадобится что-то перестроить год спустя. Вы никогда не знаете, нужно ли вам что-то восстанавливать. Вы строите его, пока он не работает, а затем забудьте об этом. Паника заставляет осознавать, что вам нужно что-то перестроить два года назад и не иметь всех частей.

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

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

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

В принципе, я ценю лагерь «проверь все, что нужно, чтобы встроить в систему контроля версий», но за последние несколько лет управление зависимостями довольно сильно развилось благодаря таким инструментам, как Maven, Ivy и NuGet.

Кроме того, на практике я нахожу проверку в двоичных файлах для создания ряда неприятных побочных эффектов. Например, Git / Mercurial на самом деле не настроены для этого, и Subversion и Perforce могут свести вас с ума при объединении веток, содержащих двоичные файлы.

Используя решение для управления зависимостями, вы указываете в файле с исходным кодом в своем проекте, от каких имен пакетов и от каких версий зависит ваш проект. Почти все инструменты управления зависимостями позволяют вам создать частный репозиторий ваших зависимостей, следуя некоторому соглашению о версиях и именах; Когда вы делаете сборку, инструмент управления зависимостями разрешит все ваши открытые и проприетарные зависимости из списка утвержденных источников, а затем вставит их в локальный кеш. В следующий раз, когда вы будете строить с теми же зависимостями версий, все уже есть и идет намного быстрее.

Затем ваш личный репозиторий может быть скопирован с помощью обычных инструментов резервного копирования файловой системы.

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

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

В моей VCS проверено множество двоичных файлов, но каждая из них - это единица выпуска некоторого продукта, который я не писал и не поддерживаю. Это может быть что-то вроде GNU ccRTP, которая выпускается в виде сжатого архива. Этот архив является моим источником, и он регистрируется вместе со всей необходимой инфраструктурой, чтобы превратить его в готовый продукт (в моем случае - файл Makefile и RPM-спецификацию) за один автоматизированный шаг. Когда появляется новая версия ccRTP, я рассматриваю новый тарбол как измененный источник: он отправляется в извлеченную копию, собирается, тестируется и передается обратно в VCS. Я сделал то же самое с коммерческими продуктами, которые не поставляются с исходным кодом (компиляторы, библиотеки и т. Д.), И он работает так же. Вместо unpack-configure-compile-package это просто unpack-package. Программное обеспечение, которое выполняет ночные сборки, неmake и получить готовую продукцию.

Большинство VCS имеют функции, которые делают читабельный исходный код более легким в обращении и более эффективным для хранения, но сказать, что они не подходят для двоичных файлов, не совсем верно, если введенные двоичные файлы возвращаются беспрепятственными. То, как VCS работает с двоичными файлами внутри, полностью зависит от того, думали ли ее авторы, что попытка сохранить только различия стоила усилий. Лично я считаю, что хранение полных копий дистрибутива ccRTP при 600 КБ более чем восполнено возможностью пометить его версию вместе со всеми другими моими источниками.

Это напоминает мне о проблеме "jars in repository", которая когда-то была в Java. Люди, создающие java-приложения, использовались для помещения их зависимостей (двоичных jar-файлов) в репозитории. Все были довольны этим, потому что у нас будет система сборки «одним щелчком», а дисковое пространство будет дешевым, так что кого это волнует? Затем появился Maven, и вы смогли избавиться от всего этого бинарного мошенничества, а с помощью локального хранилища, работающего только с кэшем, по-прежнему поддерживать сборки bullet-prof. Тем не менее, у вас есть система сборки «одним щелчком», но контроль над исходными текстами не должен перебирать двоичные файлы, которые не имеют смысла.

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

Ваш источник контроля держит источники того, что вы делаете. Если данный двоичный двоичный объект может быть восстановлен из источников, он не является источником и не должен помещаться в хранилище исходного кода. Только не восстанавливаемые капли должны в исходном контроле.

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

Итак, вставьте это, если это источник. Нет, если нет.

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

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

Посмотрите эту запись в блоге Дерека Грира на эту тему.

Я работаю над проектом с двумя разными этапами сборки

• для «сборки основной программы» требуется всего несколько двоичных файлов по сравнению с тысячами текстовых файлов с исходным кодом, поэтому двоичные файлы проверяются в хранилище. Это отлично работает.

• сборка установщика требует большого количества сторонних компонентов (некоторые из них просто копируются на установочный компакт-диск, например Adobe Reader). Мы не помещаем их в хранилище. Вместо этого эти компоненты находятся на сетевом диске (даже в более старых версиях), а сценарии сборки копируют их в нужное место. Конечно, чтобы иметь воспроизводимые сборки, любой должен быть осторожен, чтобы не изменить папку, в которой хранятся сторонние компоненты.

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

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

Однако вам не нужно хранить все в Source Control.

Одна компания держала замороженную серверную стойку (потому что ОС работала только на этом конкретном оборудовании, а набор инструментов работал только на этой ОС, а источник зависел от этого набора инструментов). Не могу проверить это в Source Control.

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

В моем сознании очень хаотично регистрировать двоичные файлы в SCM. Я запустил очень сложный проект, который имеет много зависимостей от библиотек третьей части. Принципы, которые мы приняли:

1. Весь исходный код управляется с помощью SCM
2. Все зависимости управляются с помощью Ivy, который имеет отличную интеграцию Eclipse.

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

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

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

Git LFS и git Annex делают это, но они также в некоторой степени пытаются управлять двоичными файлами, я не хочу, чтобы они это делали. Я хочу, чтобы Git сохранял только контрольные суммы и сообщал мне, изменились ли мои двоичные файлы или нет - но я не хочу, чтобы он пытался управлять ими и хранить их. Я хочу сделать это сам.

Я думаю, что git может обрабатывать небольшие и средние двоичные файлы, но я не уверен, что это правильный инструмент для управления большими двоичными файлами.