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

Question

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

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

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

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

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

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

Answer 1

Да, я храню ВСЕ, что является частью процесса доставки программного обеспечения в систему контроля версий.

Answer 2

Об этом есть две школы мысли:

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

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

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

Answer 3

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

Answer 4

Я обычно работаю с eclipse / ant над проектами java. Нет, я не держу JDK, Ant или Eclipse под контролем версий, но:

• весь мой источник
• сценарий сборки
• все сторонние библиотеки в их используемой версии (да, также junit)

Причина: у меня почти автономная система сборки, любая система с установленными jdk и ant сможет собираться без необходимости сетевого подключения (списки пакетов для внешнего javadoc также проверены) Это может быть мой macbook, рабочий стол Windows компании, любой сервер непрерывной сборки.

Answer 5

Мы используем maven , поэтому мы проверяем только код, тесты, файлы конфигурации и, конечно, pom.xml, никаких библиотек, никаких инструментов.

Answer 6

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

Answer 7

Мы не помещаем инструменты в SVN, которые пришли извне (Visual Studio, Eclipse, CDT-Plugin, ...).

Но у нас есть большой набор самописных инструментов (генераторов кода, пользовательских сборочных сборок для VS и плагина Eclipse), где мы помещаем исходный код и двоичные файлы в SVN.

Причины этого решения просты технические:

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

Answer 8

Да! мой ответ.

Я добавил инструменты сборки, такие как NUnit и NAnt, в систему контроля версий.

Основное правило для меня:

• Сервер сборки должен быть в состоянии построить решение.

И на сервере сборки, который я использую, не установлены NUnit, NAnt и т. Д.

На сервере сборки есть .NET Framework и CruiseControl.NET, и не более того ...

Answer 9

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

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

Answer 10

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

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

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