Аргументы против регистрации бинарных файлов в SCM

Аргументы против регистрации бинарных файлов в SCM
Аргументы против регистрации бинарных файлов в SCM - kilarov345 @ Unsplash

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

Они знают, что это плохая практика, но они думают, что «это работает» и на самом деле это не проблема, даже если многие люди знают о Maven и других инструментах для сборки помимо Ant. И продакт-менеджеры, и программисты (около 50 человек) готовы выслушать любые аргументы против и даже признать, что это пустая трата резервного пространства, но я хочу быть действительно убедительным, потому что изменение привычки потребует больших усилий. Какие аргументы вы используете для поддержки изменений?

Редактировать: хорошо, имеет смысл различать файлы, которые почти не меняются, например зависимости, и сгенерированные файлы. Тем не менее, меня интересуют доводы против последнего.

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

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

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

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

Для бинарных форматов, которые действительно представляют исходники проекта, такие как художественные активы, это неудачный, но необходимый шаг. Однако выходные данные сборки не являются источниками. Нет необходимости объединять их, потому что источники могут быть объединены, а результирующий вывод сборки может быть сгенерирован повторно. Отслеживание и управление этими изменениями — 100% растрата. Это тратит впустую ресурсы SCM, хотя и не очень много, но также тратит время разработчика на преодоление ложных сбоев слияния. Время разработчика стоит очень дорого, и все, что тратит его впустую, — это рак.

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

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


LetsCodeIt, 30 мая 2023 г., 20:52