Предложения по организации коллекций проектов и командных проектов

Question

Наша компания решила начать использовать Team Foundation Server 2010 для нашего процесса разработки.

У меня проблемы с выбором структуры наших коллекций и командных проектов.

Всего у нас 9 разработчиков, каждый из которых работает над разными проектами в разное время.

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

Каков ваш подход при создании / управлении несколькими проектами, которые не обязательно взаимодействуют друг с другом? Лучше ли помещать вещи в отдельные коллекции или целесообразно, чтобы количество ваших коллекций было низким? Любая помощь приветствуется.

Answer 1

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

Каждая «Коллекция по умолчанию» является своего рода отдельным экземпляром TFS (работающим в той же среде). Идея состоит в том, что коллекции не пересекаются друг с другом, и все данные всегда остаются отдельными. Если я правильно помню (сейчас не могу протестировать, потому что мы все еще на TFS 2008), вам действительно нужно переключиться из одной коллекции в другую, чтобы начать работать в этой коллекции. Я не верю, что вы можете открыть две коллекции одновременно.

Answer 2

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

Answer 3

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

Для внутренней разработки жизненный цикл данного приложения, как правило, "навсегда", поэтому я буду видеть, как они используют командный проект для бизнес-приложения.

Единственная причина, по которой такой маленький магазин, как ваш, хотел бы создавать дополнительные коллекции проектов, заключается в том, что вам необходим такой уровень изоляции. Вот некоторые причины: 1. У вас есть правовая или нормативная причина для сохранения исходного кода и работы изолированными (правительство, конфиденциальность, PCI и т. Д.). 2. У вас есть клиенты, которые хотят, чтобы их рабочие элементы и код были переданы им в конце проекта. Некоторые могут захотеть историю, поэтому легко и просто предоставить им собственную коллекцию проектов вместо того, чтобы сортировать данные других.

Если вам нужна дополнительная информация, это может помочь опубликовать, какова природа проектов.