где я должен установить средства разработки?

Question

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

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

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

Так что мне интересно ...

Это работает как рекламируется? кто-нибудь пробовал?

Кроме того, учитывая структуру папок репозитория, приведенную ниже, если у вас есть несколько разрабатываемых программных продуктов, вы устанавливаете копию, скажем, nunit, в папке Extras каждого проекта, или вы устанавливаете одну и только одну в Общая папка репозитория будет использоваться для всех проектов? (Последнее заставляет меня думать, что между проектом и инструментом существует логическое и физическое несоответствие, но первое означает, что может быть множество разных инструментов, потому что проект a использует nunit 2.4.5, а проект b использует nunit 2.4. 8 и т. Д. - вместе со всеми другими инструментами / версиями)

Repository>Common
Repository>ProjectName>Extras
Repository>ProjectName>Trunk
Repository>ProjectName>Tags
Repository>ProjectName>Experiments

Я не уверен, имеет ли эта последняя часть смысл ... дайте мне знать, и я уточню.

Answer 1

Мы используем папку (или проект) под названием «Vendor». Все наши зависимые библиотеки, которые не разрабатываются собственными силами, а также любые инструменты включены туда. Он находится на верхнем уровне исходного дерева.

Answer 2

Наша команда разработчиков использует виртуальные машины. Таким образом, новый член команды получает виртуальную машину с уже установленной Visual Studio и SQL Server 2008 Express. Эти коммерческие инструменты, которые мы не можем изменить, отсутствуют в нашей системе контроля версий. Но у нас есть версионная документация о том, какие инструменты установлены на образе виртуальной машины.
С помощью инструмента с открытым исходным кодом Fitnesse проверка в хранилище работает хорошо. Как вы говорите, проверка новой версии и обновление ссылок позволяет мгновенно обновиться для команды. Но в этом случае это работает хорошо, потому что нет процесса установки инструмента.
В нашем случае у нас есть инструменты среднего уровня, такие как xUnit, FxCop, ccNet, которые включены в проект. В основном мы работаем с одним крупным проектом, поэтому все идет под него.
Для предыдущего работодателя у нас была область Common tools в хранилище. Из-за того, что разные проекты не хотят одновременно переходить на новую версию инструмента, каждую версию инструмента нужно было поместить в отдельную папку. Создание этой области хранилища немного отличается от общего файлового ресурса. Контролируемое хранилище хранилище все еще может быть полезным. Инструменты управления версиями позволяют вам указывать «представления» для сброса всех необходимых файлов проекта.

Answer 3

Я не "устанавливаю" и не помещаю инструменты третьей части в репозиторий. Они идут на файловом сервере, но не в репо.

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

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