Какие преимущества TFS 2010 имеет по Axosoft OnTime?

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

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

Недавно мы рассмотрели ряд возможных альтернатив для замены системы, включающей SVN и систему ручного отслеживания ошибок (таблицы Excel). Своевременность была оценена, но сочтена слишком дорогой и сложной.

В конце концов, мы решили продолжить использование SVN, но радикально пересмотрели (упростили) структуру наших репозиториев и решили объединить SVN с системой отслеживания проблем FogBugz. Интеграция между этими двумя системами была довольно рудиментарной "из коробки", но потребовала лишь небольших усилий с нашей стороны для достижения гораздо более тесного уровня интеграции, которого мы желали. Конечно, гораздо МЕНЬШЕ усилий, чем в моем предыдущем опыте развертывания TFS .

Наша система SVN / FogBugz теперь также интегрирована с пакетом автоматизации сборки FinalBuilder.

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

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

Теперь я использую Subversion / Trac, которая выполняет свою работу (а настройка рабочего процесса в Trac настолько проста, что это неинтересно по сравнению с TFS).

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

Я использовал bugzilla в сочетании с Perforce в течение нескольких лет и обнаружил, что оба действительно очень хороши в своих индивидуальных вещах, работая в очень небольшой команде (2-3 человека), но страдали от недостатка интеграции между ними и от некоторых мелких идиосинкразий, к которым потребовалось время, чтобы привыкнуть.

Недавно я перешел на новую работу, где широко используется TFS. В этой компании 4 основные команды по 10-12 разработчиков в каждой, разделенные на группы по проектам ниже этого уровня, и именно в такой среде TFS действительно сияет. На мой взгляд, это самые большие преимущества:

1) Интеграция с Visual Studio - это не просто случай уменьшения количества открытых окон, это действительно ускоряет процесс и облегчает вашу жизнь. Такие вещи, как VS, автоматически проверяют файлы для вас во время работы (нет проблем со случайными проверками из-за редактирования без блокировки), возможность синхронизировать локальные + TF сборки, возможность быстро сравнивать локальную версию с предыдущими ... да, вы можете получить Сторонние плагины для интеграции, но не до этого уровня и с такой же стабильностью.

2) Коммуникационные возможности - простые вещи, такие как интеграция с Live Messenger (при условии, что вы правильно настроили TFS), отлично подходят для больших команд. Мы используем WLM для общения в офисе и для совместной работы, поскольку это намного быстрее, чем идти к кому-то другому каждый раз, когда вам нужно задать быстрый вопрос.

3) Связывание сборок / списков изменений с задачами - Да, другие SCM делают это, но опять же, это делается очень хорошо, интегрированным способом ... Я думаю, в TFS нет ничего особенного, но лично мне нравится, как он это отслеживает.

4) Простота объединения / редактирования без блокировки. У меня был опыт работы с некоторыми другими инструментами слияния, и TFS работает достаточно хорошо, делая слияние после одновременного редактирования довольно простым. Это очень похоже на perforce в этом отношении, но также с обычно довольно эффективным инструментом автоматического слияния, который я использую для крошечных правок, которые, как я знаю, не могут вызвать никаких потенциальных проблем с правками, над которыми работают другие разработчики.

5) Автоматическое строительство / управление строительством. Работа с парочкой больших решений, содержащих 20-30 проектов, которые зависят друг от друга, это находка. Мы настроили его ставить в очередь сборку каждые 20 минут, ЕСЛИ что-то изменилось, и когда что-то произошло, это занесено в журнал истории… так легко увидеть, когда вам нужно обновить локальные библиотеки.

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

Итак, перевод на бизнес-план.Я бы сказал, что если вы являетесь разработчиком программного обеспечения Microsoft с большой / несколькими командами, то экономия времени и повышение производительности, которые вы увидите в результате вышеупомянутых функций, стоит вложений в их настройку. В большинстве случаев его можно использовать бесплатно, поскольку у вас, вероятно, будет подписка на MSDN (возможно, некоторые проблемы с CAL, но я не уверен), поэтому ваши самые большие расходы будут на обучение пользователей и настройку.

В настоящее время избегайте TFS!

Я бы придерживался SVN + FinalBuilder, а затем выбирал между FogBugz или CounterSoft Gemini.

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

В любом случае, я бы посоветовал попробовать его самостоятельно (или в небольшой команде) на каком-нибудь очень маленьком, но реальном проекте - возможно, вам понадобится какой-нибудь инструмент. на однократной основе код, который можно выбросить или легко перенести в другую систему, потому что он небольшой. Нет ничего лучше, чем пользоваться системой!

Я использовал OnTime и Subversion. Я не использовал TFS в качестве средства отслеживания ошибок, но я использовал его для управления версиями. Его часть, связанная с контролем версий, по сути, по-прежнему остается плохим старым Visual SourceSafe. Если вы в настоящее время используете Subversion, вы будете ругаться каждый раз, когда вам нужно будет переименовать файл или, не дай бог, удалить файл, а затем создать его с тем же именем - не говоря уже о ветвлении или слиянии. В посте сложно передать, насколько она примитивна и хрупка как система управления версиями - вот почему вам действительно нужно ее использовать. Вы поймете, что я имею в виду, когда обнаружите, что застряли с файлом, который не можете ни зарегистрировать, ни удалить, и какой-нибудь бессмысленной ошибкой. Не то чтобы Subversion идеальна - но она на десять лет опережает VSS!

Рабочий процесс в TFS, с которым я лишь мельком поиграл, мне кажется очень "тяжелым". То есть он действительно ограничивает пользователя этим рабочим процессом и требует множества шагов, которые часто не нужны. Это может помочь, но также может легко помешать. Хорошая система обеспечивает рабочий процесс, когда это необходимо, но позволяет обойти его, когда он просто мешает.Когда мы использовали OnTime, мы обнаружили, что даже его относительно ненавязчивый рабочий процесс часто доставлял больше хлопот, чем оно того стоило. Конечно, все зависит от специфики вашей ситуации. Как вы сейчас используете рабочие процессы OnTime и что вы хотите от TFS, чего не предоставляет OnTime?

Связывание ревизий с ошибками также можно сделать с помощью Subversion. Он поддерживает какой-то механизм расширяемости - подробностей не помню, но FogBugz его использует (мы перешли на него после OnTime). Связывание со сборками можно выполнить, добавив простую команду тега svn в сценарий сборки. Интеграцию Visual Studio можно выполнить с помощью VisualSVN .

Стоимость также является огромным недостатком TFS. Это очень дорого для того, что он делает, особенно если учесть, насколько хорошо он это делает. Да, это «бесплатно» , если у вас все равно должна быть подписка MSDN для каждого разработчика - но нужно ли без TFS? Subversion бесплатна, точка. OnTime и FogBugz стоят гораздо дешевле.

Я не уверен насчет лицензирования Axios OnTime, но если у вас есть подписка MSDN, тогда это без дополнительных затрат. См. Сообщение в блоге здесь

. Я использовал TFS 2008 только для контроля версий, и хотя это хорошее обновление с VSS, некоторые вещи, которые мы пытаемся сделать, не совсем соответствуют тому, что мы ожидаем. Тем не менее, я написал небольшое небольшое веб-приложение, которое заполняет эти пробелы. Было довольно легко разработать против использования API, и есть множество надстроек, помогающих с конкретными задачами.

Не уверен в TFS, но пользовательский интерфейс OnTime не интуитивно понятен. Также мне не нравится, что у вас есть разные поля для ошибок и Задачи. Конечно, вы всегда можете добавить свои собственные поля, но макет по умолчанию должен быть готов к использованию.

Мы решили использовать только «Ошибки», даже если это задача.

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

Сожалеем, что вы хотите избавиться от SVN. Это трудное решение.