Значение Microsoft Team System только внутри команды разработчиков - PullRequest
1 голос
/ 30 июля 2009

Microsoft Team System представляется отличной платформой для внедрения систем, ориентированных на процессы, однако, если вы ограничите доступ для BA, PM и бизнес-пользователей и будете просто использовать его в команде разработчиков, будет ли он иметь большую ценность, чем просто с помощью Visual Studio Professional, SourceSafe, инструмента отслеживания дефектов и сервера непрерывной интеграции, такого как CruiseControl или TeamCity?

Ответы [ 3 ]

5 голосов
/ 30 июля 2009

Да. Каждая упомянутая вами технология замены - это то, что поддерживается пакетом Team System (в этом или следующем выпуске). Все эти компоненты предназначены для интеграции и работы друг с другом в TFS. Это высокий приоритет команды TFS для всех компонентов. Результатом является набор функций, которые в большинстве случаев легко интегрируются друг с другом.

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

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

1 голос
/ 30 июля 2009

Конечно, это имеет значение. В составе командных SKU есть масса клиентских функций (не позволяйте названию обмануть вас - это в первую очередь просто новые «супер-премиумные» версии для кухонных раковин, которые также имеют приятный бонус включения серверной клиентской лицензии для TFS.) Точные характеристики доступны здесь: http://www.microsoft.com/visualstudio/en-us/products/teamsystem/default.mspx

Если обратить особое внимание на возможности совместной работы, опять-таки, в системе, компоненты которой были спроектированы так, чтобы «просто работать» друг с другом, была очевидная ценность. Настройка упрощена (хотя есть пути); пользовательские интерфейсы последовательны и доступны друг другу; бэкэнд обеспечивает единую службу отчетов / анализа. Если у вас большая команда, общая производительность / масштабируемость также намного превосходит возможности типичного пакета OSS на данный момент.

Вопрос в том, стоит ли он вам $$. Зачем использовать Visual Studio Professional вместо SharpDevelop? Почему SourceSafe вместо Git? Почему не Блокнот и специально помеченные папки?

Все коммерческие продукты являются коммерческими по какой-то причине (хорошо, возможно, не SourceSafe!). Если вам нужно что-то с широким набором функций, тесной интеграцией, четко определенным жизненным циклом поддержки и тестирования, хорошей подгонкой, завершением и т. Д., То, как правило, стоит потратить $$ и позволить своим разработчикам продолжить свою работу. Если вы не возражаете заняться настройкой и устранением неполадок самостоятельно, переключаясь между несколькими приложениями в рамках рабочего процесса разработки, теряя возможность запрашивать и составлять отчеты по групповой статистике в целом и т. Д., То непременно переходите на открытый исходный код - многие разработчики OSS инструменты сейчас очень прочные.

1 голос
/ 30 июля 2009

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

Некоторые функции, которые предоставляет TFS, которые мы используем: безопасность, отчетность, управление рабочим процессом, интегрированные сборки, оповещения по электронной почте, ветвление / слияние.

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

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

Мои мысли.

...