TFS 2008/2010 против Jenkins для непрерывной интеграции

Есть ли у кого-то особый опыт использования TFS 2008/2010 и Jenkins для непрерывной интеграции (CI)? Мы пытаемся решить, какой сервер CI использовать. Наша команда работает исключительно в Microsoft.NET/Visual Studio 2010/С#. У нас есть следующие требования:

  • Автоматически создавать наш веб-проект на каждом этапе регистрации.
  • Запускать единичные тесты с каждой сборкой.
  • Автоматически развертывать зеленые сборки для среды разработки и/или тестирования.
  • Предоставить красивые отчеты.
  • Предоставлять уведомления о создании/развертывании по электронной почте.

Я понимаю, что установка инструмента не обязательно даст нам эту функциональность из коробки и что нам нужно будет интегрироваться с другими инструментами, такими как MSBuild, чтобы достичь этого.

Я ищу конкретные функции, которые Jenkins имеет, что TFS 2008/2010 не делает или наоборот. Также, который легче поддерживать, использовать и т.д.

ОТВЕТЫ

Ответ 1

Я бы очень рекомендовал использовать Jenkins - он выполнит все ваши требования из коробки, кроме, возможно, # 3, но если вы сможете script развертывания, то он также сможет это сделать.

Вот несколько ссылок, которые помогут вам создать и запустить свои сборки:

Блог о создании .NET в Jenkins

Установщики Jenkins для Windows

Установка ведущего и подчиненных Jenkins в качестве служб Windows

Отказ от ответственности: у меня нет опыта работы с TFS, но я считаю, что открытые решения почти всегда более гибкие и расширяемы (и дешевле!), чем проприетарные продукты.

Ответ 2

Поздно к этой игре, но я использовал и TFS 2010, и Jenkins для CI. TFS 2010 имеет минимальный набор инструментов CI. Однако, когда вы хотите создать конвейер CI, это совершенно другая история, в то время как Jenkins может легко создать конвейер.

Если вы ищете только CI для одной сборки, то нужно работать. Однако, когда дело доходит до всего конвейера, Дженкинс - это путь. С TFS это можно сделать, но Дженкинс - лучший выбор.

Здесь быстрые пункты:

TFS:

  • С помощью определения сборки вы можете компилировать, выполнять тесты, возвращать набор изменений /workitems, отправлять электронную почту при сбое сборки

  • естественная интеграция с визуальной студией

  • чрезвычайно сложно создать конвейер CI. Требуется пользовательский обработчик и расширенная работа рабочего процесса. Не так интуитивно, как создание определения сборки.

  • Из-за 3-го пульта нелегко поддерживать/настраивать/масштабировать конвейер CI

Дженкинс

  • Необходимо создать конфигурационный файл msbuild для CI, который не сильно болит по сравнению с созданием конвейера CI с использованием TFS. Тем не менее, TFS дает лучший/простой инструмент для создания определения сборки. однако неплохо создать файл конфигурации для msbuild для проекта.

  • Создание конвейера CI очень просто. Просто соедините их с помощью триггера задания вверх/вниз по потоку джиткингов и передачи артефакта из предыдущего задания.

  • Поскольку Jenkins очень гибкий, легко создать плагин jenkins для удовлетворения ваших собственных потребностей и предоставить его сообществу open-source:)

В заключение, если вам нужна полная автоматическая сборка, тестирование и развертывание, обратитесь к Jenkins. Если вам просто нужно только строить и тестировать, TFS может дать вам преимущество над Дженкинсом.

Ответ 3

Если вы используете Team 2010-2012, нет никакой причины привлечь Дженкинса. Команда имеет все функции, которые вы указали, и процесс сборки смехотворно гибкий.

Обратите внимание, что если вы застряли в Team 2008 или ранее, вам следует серьезно взглянуть на Jenkins - 2008 и более ранние версии довольно примитивны и негибкие по сравнению с 2010 годом или позже.