Сборка основы команды или TeamCity?
Мы главным образом магазин MS на работе, делающей.NET разработка LOB. Мы также используем Динамику MS для нашего приложения CRM... все devs в настоящее время используют VS/SQL Server 2008. Мы также используем VSS, но все ненавидят его на работе, и это быстро продвигается.
Мы начинаем нашу инициативу для реализации TDD через команду (~dozen люди). Я получил настройки TeamCity и имею мои первые автоматизированные сборки, выполняющие успешно использование 2008 sln разработчик и также использование SVN, что у коллеги была установка, кто делает анализ управления исходным кодом. При демонстрации к управлению я думаю, что они начали вложиться в мою нефть змеи и вывели предложения изучения TFS.
Это добавило ключ, что я запланировал нашу архитектуру TDD; хорошим способом, хотя, потому что я всегда предполагал, что TFS был просто слишком дорогим и не стоил того для нашей команды (и я видел то же в других магазинах, я работал в / знают о). Я действительно чувствую, что MS является годами позади в области TDD/CI и что сторонние продукты были, вероятно, намного лучше и более сформировавшимися... Я все еще должен провести большое исследование, но я полагал, что приехал сюда, чтобы видеть, использовал ли кто-либо на самом деле обе системы.
Я понимаю, что TFS охватывает намного больше затем просто сервер сборки..., но я не хотел делать это слишком широко вопроса по крайней мере нарочно. Каковы практические профессионалы/недостатки использования TFS/TFB вместо TeamCity - например, какие преимущества мы теряли бы/получали бы? Кто-либо здесь на самом деле использовал обе системы (TFS для TDD/CI и TeamCity/SVN) и может говорить с практической точки зрения?
Я сделал некоторый поиск по этой теме, и одно сообщение, на котором я нашел здесь ТАК упомянутый, что недостатки TFB были этим только, поддерживало MSBuild. Я был планированием использования FinalBuilder с TeamCity; и кажется, что это также поддерживает TFS также...
Спасибо за любой совет
Править: Кто-либо использовал TFS в качестве их сервера Сборки/CI и может сказать об историях успеха/отказа?
4 ответа
Мы представляем собой небольшой магазин разработки и решили, что Team Foundation Server несет для нас слишком много накладных расходов. Раньше мы писали собственные сценарии MSBuild для запуска из командной строки, но после того, как мы обнаружили TeamCity, мы переместили на него весь процесс сборки.
Мы обнаружили, что TeamCity прост в использовании и настройке, а JetBrains обеспечивает отличную поддержку и документацию. Они также находятся в гораздо более быстром цикле выпуска и обновления, чем Microsoft.
Их поддержка управления исходным кодом SVN превосходна, и нам нравится тот факт, что они поддерживают как MSTest, так и NUnit для модульного тестирования.
Нам также понравился тот факт, что версия TeamCity Professional была бесплатной, поэтому мы могли оценить ее, чтобы увидеть, работает ли она для нас. Мы не достигли того количества конфигураций проекта (20), которое потребовало бы обновления до версии Enterprise.
Преимущества TFS - это одна интегрированная среда, поддерживаемая Microsoft. Мне лично не нравится TFS для управления версиями, и у меня с ней возник ряд проблем. Это неуклюже, но имеет преимущество интеграции с VS (которая также доступна в VisualSVN, но не так надежна).
Лично я думаю, что вам было бы намного лучше использовать SVN / TeamCity. Просто с ним легче работать, и он ведет себя более ожидаемо. Как и в случае с большинством программного обеспечения с открытым исходным кодом, оба они постоянно развиваются и всегда будут иметь новейшие и лучшие функции до Microsoft. Интеграция между двумя действительно хороша, и я не обнаружил фатальных недостатков в системе. Я постоянно настаиваю на том, чтобы пойти по этому пути в моей нынешней компании (мы используем TFS), так как считаю, что это намного лучший рабочий процесс. В качестве дополнительного преимущества это значительно дешевле, чем использование маршрута TFS.
Я также использовал FinalBuilder с TFS - мой вопрос: что вы действительно покупаете с FinalBuilder, чего нельзя сделать с NANT / MSBuild? Ответ в моем магазине, к сожалению, очень мало IMO.
Прежде всего, см. Этот пост:
SVN против Team Foundation Server
Что касается вашего вопроса о том, какая среда лучше поддерживает TDD и тому подобное, мои два цента заключаются в том, что система управления сборкой имеет гораздо меньшее значение, чем то, что в сам файл сборки. В вашем файле Ant или MSBuild должны быть целевые объекты, которые будут выполнять ваше тестирование. С MSBuild или Ant вам не нужно использовать набор тестов MS. Вы все еще можете использовать nUnit или что угодно еще. Это означает, что не имеет значения, вызывает ли TFS ваш файл MSBuild, или CruiseControl, или TeamCity. Все умные элементы находятся в файле сборки и в инструментах, которые вы с ним интегрируете.
Я лично предпочитаю не связываться с методами работы TFS, поскольку у вас есть гораздо больше свободы при гораздо меньших затратах с доступными инструментами тестирования с открытым исходным кодом. TFS также скоро получит серьезное обновление. Если вы собираетесь использовать TFS, я советую хотя бы подождать до выхода 2010 года. Сосредоточьтесь на том, чтобы ваши файлы MSBuild были настолько хороши, насколько это возможно прямо сейчас.
При этом я должен признать, что у TFS одна из самых хороших систем сборки (2005 год был ужасным, 2008 год был хорошим). Возможность легко настраивать уведомления и процесс выпуска внутри кода .NET была довольно крутой - у вас был гораздо больший централизованный контроль над политикой сборки и выпуска, чем у нас с CruiseControl.NET.
Итак, я использовал TFS и SVN / CCNet. Я не могу много говорить с TeamCity. Но ИМО система управления сборкой должна быть довольно независимой от того, что создается и как это создается.Для нас дополнительный контроль в процессе управления выпуском, который нам дала TFS, просто не был достаточным бонусом, чтобы оправдать значительно возросшие административные усилия полностью интегрированного решения TFS. Этого было недостаточно, чтобы оправдать дополнительную стоимость лицензии TFS, которая может быть значительной.
На этот вопрос есть много хороших ответов о TeamCity. Он не сравнивается с TFS, но может пролить свет на TeamCity для вас.
Я использовал обе системы, и у меня был успех с обеими, но TeamCity была намного проще. TeamCity было легко установить и настроить. TFS - нет. TeamCity надежен, его легко поддерживать, и он просто работает. Разработчики из JetBrains проделали огромную работу, реагируя на запросы сообщества. Каждые 6-8 месяцев они выпускают релиз, который приносит реальную пользу. TFS работает с циклом в 2 года и более.
TeamCity дает вам больше выбора в том, как вы собираете и какой контроль исходных текстов используете. Это не все в одном, но иногда это хорошо. Кроме того, у него хороший набор точек расширения. Мы также были очень довольны агентской моделью.
Я прошел через 3 абсолютно безболезненных обновления в TeamCity. Одно обновление TFS, которое мы делали, привело к тому, что наша сборка и контроль исходных текстов не работали 3 дня. Я являюсь администратором TeamCity в нашем проекте, и это занимает пару часов в месяц. TFS занимала пару дней в неделю.
TeamCity + SVN + VisualSVN была самой гладкой средой, в которой я когда-либо работал. TFS была в целом гладкой в повседневной работе, но только если кто-то был рядом и поддерживал ее в рабочем состоянии.
Надеюсь, это поможет