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

Ответ 1

На этом есть две мысли:

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

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

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

Ответ 2

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

Ответ 3

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

Ответ 4

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

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

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

Ответ 5

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

Ответ 6

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

Ответ 7

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

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

Ответ 8

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

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

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

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

Ответ 9

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

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

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

• Сервер сборки должен иметь возможность создавать решение.

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

Сервер сборки имеет платформу .NET и CruiseControl.NET, и не намного...

Ответ 10

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

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

Было несколько упражнений, которые запускали диспетчер liscence, но после этого все было хорошо.

Ответ 11

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

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

Ответ 12

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

Ответ 13

Мы сохраняем 2 репозитория: "Быстрое перемещение" содержит наш код с ветвями для релизов и патчей.

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

Есть две причины хранить инструменты в каком-то репозитории:

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

Ответ 14

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

Разработчик должен иметь возможность делать чек и строить всего за пару шагов. Там размещается там, где это занимает весь день.

Ответ 15

Мы не делаем - на самом деле, я никогда не работал на месте, которое это делало.

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

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

Ответ 16

Не инструмент, а script. Мы используем Ant. Файл build.xml script, который управляет процессом, находится под контролем источника.

Ответ 17

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

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

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

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

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

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

Затем я всегда могу проверить проект, запустить "идти", и он должен построить проект (если у меня установлен JDK/.Net Framework).

Ответ 18

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

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

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

Павел.

Ответ 19

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

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

• Все Make файлы, тесты скриптов и все, что связано с ним

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

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

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

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

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

Ответ 20

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

Ответ 21

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

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

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

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

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

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

Ответ 22

Нет, я не потому, что я использую MsBuild, и это часть платформы .NET в любом случае