Поддерживаете ли вы инструменты сборки в управлении версиями?

Question

У вас есть инструменты, необходимые для создания вашего проекта, под контролем версий?

Если да, то каковы ваши рекомендации относительно того, какие инструменты включить? Полагаю, никто не переводит Visual Studio в систему управления версиями, но как насчет вашего юнит-тестировщика? Исполняемый файл Nant / Ant / Maven?

Как насчет внешних зависимостей? У вас есть Boost в управлении версиями? JDK? NUnit / JUnit? Где вы рисуете здесь предел?

(см. Также этот вопрос ).

EDIT: Думаю, мой вопрос был не совсем ясен: я не хотел знать, держали ли вы их в режиме контроля версий или какой-то общий диск. Я действительно хотел узнать, проверяли ли вы инструменты, необходимые для встраивания проекта в систему управления версиями вместе с проектом, чтобы при проверке проекта вы автоматически получали инструменты.

Как общее продолжение для тех, кто отвечает «нет»: каков ваш процесс отслеживания этих инструментов? Ваш скрипт загружает их?

Answer 1

Мы магазин Maven и ранее магазин ANT. В дни ANT мы проверяли зависимые библиотеки в структуре проекта. Теперь мы проверяем только ресурсы, необходимые для сборки приложения (pom, исходный код, ресурсы и т. Д.), Но определенно нет библиотек.

Answer 2

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

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

Answer 3

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

Однако мы сохраняем все остальное в системе контроля версий - все сценарии сборки, сценарии SQL, файловые зависимости (то есть ссылочные библиотеки, не установленные в GAC или программных файлах) и т. Д.

Answer 4

У нас есть 2 хранилища: «Быстро движущийся» содержит наш код с ветками для выпусков и исправлений.

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

Существует две причины для хранения инструментов в каком-либо хранилище:

1. Любой разработчик может легко найти нужные инструменты.
2. Можно создать копию любой официальной сборки из прошлого, чтобы можно было создать патч.

Answer 5

Что входит в наш репозиторий:

• Любой код, который я пишу, или любой мой ученик пишет

• Все Make-файлы, тестовые сценарии и тому подобное

• Внешние инструменты, которые мы модифицировали (мы обычно добавляем весь инструмент, а не только патчи) включая версию Эндрю Хьюма Make

Что не входит:

• Исходный код для всех используемых нами компиляторов

• Источник для оболочки

Если бы у нас были лучшие инструменты, мы поместили бы это все в хранилище. Чтобы получить отличную книгу о том, как это сделать и отслеживать все версии всего с начала времени, ознакомьтесь с книгой по проекту Digital SRC Vesta .

Answer 6

Код, сборка, тестирование, документирование и любая другая автоматизация. Я вообще даже помещаю графики и любую другую относящуюся к проекту документацию также в хранилище.

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

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

Paul.

Answer 7

Лично я предпочитаю разместить как можно больше инструментов сборки в репозитории, но я рисую линию в IDE и компиляторе.

Мне нравится думать, что это компромисс: я могу выбирать между:

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

Для чего-то вроде IDE проще просто задокументировать, и у большинства разработчиков это уже установлено. Для Ant, Nant, JUnit и т. Д. Его легче включить в репозиторий.

Мне особенно нравится иметь Ant / Nant в репозитории, потому что он позволяет мне включать скрипт go.bat / go.sh так:

set ANT_HOME=tools/apache-ant-x.x.x
tools/apache-ant-x.x.x %*

Тогда я всегда могу оформить проект, запустить «go», и он должен создать проект (при условии, что у меня установлен JDK / .Net Framework).

Answer 8

У нас нет - на самом деле, я никогда не работал в таком месте.

Мы храним такие вещи, как Makefiles, и собираем сценарии и тестируем сценарии в контроле исходного кода, но никогда не компилятор ant или C или подобные.

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

Answer 9

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

Основная проблема использования tarball или репозитория со всеми вашими инструментами:
Установка их всех занимает слишком много времени, и через несколько лет у вас всегда возникают проблемы с его возобновлением.

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

Иногда просто не удается установить систему сборки на более новую версию ОС.
Или более новая версия некоторых инструментов (например, Visual Studio 2025) будет использовать другие файлы проекта, и «полная совместимость вверх» не будет выполнена.

Также лицензии проблематичны через несколько лет. Можете ли вы получить новый ключ активации в разумные сроки? Компания все равно поддерживает это?

Виртуальные машины просто содержат все необходимые установленные инструменты и запускаются через несколько минут.
Хорошо, особенно если я хочу изменить только несколько строк кода.

Answer 10

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