Это хорошая практика для хранения среды выполнения фреймворка под контролем исходного кода?

Я знаю, что многие магазины программного обеспечения держат двоичные файлы под контролем исходного кода . Однако наш магазин пришел для хранения целых фреймворков в репозитории: среда выполнения DirectX, CUDA, nVidia Optix, что угодно.

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

Я никогда не видел такой шаблон использования. Считаете ли вы это хорошей практикой?

[EDIT:] У меня нет проблем с изолированными бинарными файлами сторонних разработчиков. Вопрос относится ко всем средам исполнения фреймворка, обычно состоящим из 10+ двоичных файлов. В качестве крайнего примера возьмем Windows SDK (который мы не храним в хранилище, слава богу, но я не вижу принципиальной разницы).

Двоичные файлы обычно не подходят для системы контроля версий, потому что:

• им не нужны функции контроля версий (слияние, различие)
• они увеличивают размер репо ...
• ... это важно, потому что вы не легко удаляете версию из VCS (VCS созданы для хранения истории), в отличие от хранилищ артефактов, таких как Nexus , которые являются простыми общими каталогами (их легко очистить: cd+ rm!)
• на них следует ссылаться в VCS в виде текста , объявления пути + версии: таким образом вы можете сохранять соответствующую историю , записывая любое изменение двоичной версии как изменение в этом текстовом файле (например, pom.xml, если вы используете Nexus например)

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

Кроме того, настройка среды отличается от разработки. Мы в основном разрабатываем на Python, и у него есть инструмент под названием virtualenv, который позволяет вам создавать легкую изолированную среду (включая библиотеки) для проекта. Когда мы проверяем наши источники, у нас есть сценарий установки, который создает этот virtualenv. Используя манифест, это указывает, какие версии библиотек необходимы и другие подобные вещи. Ничто из этого не контролируется версией. Только установочный скрипт есть.

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

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

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

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

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

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

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

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

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

Что касается хранилища наворотов. Это проблема, только если ваша VCS хранит полную локальную копию (это делает git, а cvs нет), поскольку клонирование и / или обновление будет медленным. В свою очередь, у вас будут копии на каждом компьютере разработчика, что может спасти вашу компанию, если однажды по какой-то причине ваша централизованная схема резервного копирования не будет выполнена.

Это вопрос приоритета или политики. Пока решение является обдуманным, я буду в порядке с этим.