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

Question

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

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

Мы рассматриваем управление жизненным циклом приложений на основе VS TFS 2010 для нашей организации. мы надеемся, что VS TFS 2010 поможет нам оптимизировать следующий

1) Требования к управлению 2) Исходный код управления Version 3) Сборка автоматизации 4) Управление Test

просто интересно, это кто-нибудь есть опыт использования VS TFS 2010 и хотели бы поделиться своим опытом? есть ли какие-то стоящие альтернативы VS TeamSystem?

Answer 1

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

Я не использовал TFS 2010, но я использовал 2005 Team Suite, включая поддерживаемые версии TFS и Visual Studio. Мы не продвигались вперед до 2008 года или 1020 из-за того, насколько необычно сложно было установить версию 2005 года. Однако, как только мы его установили ... Это понравилось. Инструменты управления проектами были интуитивно понятны и хорошо работали. Настройка сборки была легкой, и я сделал все, что хотел, чтобы это делалось просто и эффективно.

С тех пор, однако, мы использовали инструменты с открытым исходным кодом, чтобы делать то же самое. Как я уже сказал, установка 2005 года была NIGHTMARE, и хотя версия Team Foundation Server 2010 года устанавливает ОЧЕНЬ легко (я сам ее протестировал и продемонстрировал ее бедной команде, которая помогла с версией 2005 года просто показать им, насколько это лучше), я не смог убедить свою команду дать ему второй шанс. Они решили придерживаться инструментов, которые не нужно было обновлять так часто, и их было легче обновить, когда это нужно было сделать.

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

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

Что касается альтернатив - это не с открытым исходным кодом, но у Atlassian есть хороший набор инструментов. Они хорошо работают для Java, и мы используем некоторые из них в нашем магазине .NET. Мы используем SVN для управления версиями. Это единственное, что мне больше нравится в нашей новой среде, чем в Team Team.

Answer 2

Я начал работу с новой компанией 2 месяца назад, которая использует исключительно TFS 2010 (для управления версиями и отслеживания задач/задач), и я не смог с ней справиться. Раньше я в основном использовал SVN для управления версиями и либо OnTime (Axosoft), либо Fogbugz (Joel Spolsky) и любил их обоих.

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

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