dwarwood спрашивает:
И есть вопрос, как к единственному человеку, светившему тот факт, что есть живой опыт использования Team Foundation. Вопрос такой - почему __не стоит использовать__ subj в командах, находящихся в процессе становления/реорганизации. (если мнение - наоборот, стоит, то тоже почему)
Я должен сразу признаться, что сварщик я не совсем настоящий. Лично я использовал TFS немного и впечатления имею очень субъективные. Илья и Дима общались с ним гораздо больше, так что может откомментируют. К тому же у нас была очень странная среда - VPN в Штаты и другие хитрости. Это, конечно, наложило свой отпечаток.
Итак, впечатления в произвольном порядке.
Понравилось, что там есть не только сорс-контрол, но и управление требованиями и багами. Причем все это прямо внутри студии. Приятно. Но все какое-то такое технологичное, от начала до конца сделанное программистами. То есть все работает, но чувствуется, что это некий generic interface. Наверное, сильно настраивается, но особого удобства нет.
Workflow почти не поддерживается. Скажем, о правилах работы со статусами багов надо просто договориться устно. Если кто-то что-от не понял, то он запросто может сделать все неправильно. Система ему мешать не будет.
Впрочем, это все придирки. Эта часть работает вполне адекватно. У нас, вон, сейчас и вовсе какое-то доморощенное решение на базе SharePoint используется. Пожалуй, пока менее удобно, чем TFS.
Сам же сорс-контрол не понравился. Если сравнивать его с VSS и SVN, то я бы его по удобству поставил на последнее место. Ясно, что он продвинутей VSS, там некоторые фичи правильно сделаны. Но зато некоторые нужные вовсе не сделаны. Вот некоторые особенности:
- Файлы чекинятся пачкой, а не по одному. Это хорошо.
- Свой чекин ты можешь связать с багом или требованием. Можно настроить и так, чтобы ты обязан был связать. Не уверен, что это хорошо и нужно для маленькой команды. Мы ведь всегда спешим, не всегда есть время под каждое исправление свою задачу сделать.
- Есть еще возможность положить код на сервер, но не чекинить. Т.е. он уже и не потеряется, но еще и не помечен как готовый. Вроде, фича нужная, но я не видел, чтобы ее кто-нибудь использовал.
- Не нашел возможности в сорс-контроле подликновать папку к другим папкам. Это есть и в VSS (share), и в SVN (externals), и мы это активно юзаем. Не знаю как без этого вообще нормально функционировать.
- Ну и наконец, файлы нужно чекаутить! :) До SVN это казалось очевидным требованием, но сейчас-то я понимаю, что это совершенно лишнее.
И вообще, весь этот сорс-контрол какой-то очень капризный. На пустом месте не хочет файлы коммитить вдруг. А в другой раз не хочет доставать, ибо ему не нравится, что локальная папка для файлов расположена не на физическом диске, а в сети/виртуальной машине. Потом что-нибудь "залипнет" в workspace и приходится вообще все зачищать и доставать заново.
Кстати, понравилась система автоматического билдания. Вполне наглядно. Правда, я не пробовал настраивать билд самостоятельно. Может оказаться довольно сложной задачей.
Постараюсь сделать выводы.
Использовать TFS для контроля исходников не хочется. Subversion гораздо приятнее во всех отношениях. Но в TFS есть баги и требования. И автоматические билды. Ну, скажем, про билды я знаю слабо, возможно их настроить не проще чем CruiseControl.NET. А вот баги - это серьезный аргумент.
К сожалению, я не знаю ни одного приличного опенсорсного баг трэкера, работающего на платформе .NET. Да и вообще, знаю только один прилично выгядящий трэкер - это Trac. К сожалению, я его не понял. Вот так посмотришь - вроде неплохо выглядит, можно понять. Начнешь пытаться его к нашим реалиям применить - никак не лезет. Ну и не родной он технологически, ибо мы не пишем на питоне. Поэтому сейчас используем простейшее решение на базе SharePoint (хотя он есть страх и ужас). Кстати, вот пример страшного баг трэкера. Все что я смотрел примерно таковы.
Вообще, я считаю, что баг трэкер должен быть либо интергирован в среду разработки (как TFS, ага), либо работать в браузере. Если он сделан одельным приложением, то запущенным его держать не хочется, ибо там куча фич, которые жрут память, а запуск происходит далеко не мгновенно, и... Короче, все кончается тем, что им никто не пользуется.
С веб-приложением как-то проще. Браузер обычно запущен, на страничку недолго перейти. Фичи все сервер реализует, он памятью жертвует. Тоже не жалко.
Кстати, про управление требованиями я забыл. Точнее, не знаю что сказать. Дело в том, что тут все очень сильно зависит от процесса, которым пользуется команда. Сейчас модно использовать всякие agile methodologies: XP, SCRUM и т.д. Обычно в них требования собираются в виде некоего неформального текста. Потом из этого текста выводятся требуемые фичи программы, а из фич уже задачи программистам. Задачи - это, по сути, те же баги, так что большинство трэкеров можно и для задач использовать. Стоит вопрос: куда записывать требования с фичами? На мой взгляд, для этого отлично подходит любая wiki. Использовать такую неформальную штуку как wiki лучше еще и тем, что все инструменты, заточенные под определенный процесс, поневоле этот процесс вам навязывают. А у вас, может, дела устроены не совсем так, как создатели процесса себе думали.
Получается, что если закрыть глаза на неидеальность сорс-контрола в Team System, использовать ее можно. Получаешь все необходимые вещи в одном флаконе. В то же время, на базе сабвершена, приличного баг-трекера и вики можно сделать более приятное решение. Но придется постараться.
Posted
Jul 03 2008, 07:38 AM
by
Andrew Mayorov