Каковы основные различия между Jenkins и TeamCity, если вы привыкли работать с Jenkins?

Эти инструменты, похоже, имеют очень похожие характеристики.

Насколько сложно было бы начать использовать TeamCity после привыкания к работе над Jenkins? Существуют ли конкретные концепции, о которых нужно знать?

TeamCity:

Это выглядит лучше, если это важно для вашей команды, тогда оно должно определенно влиять. Тем не менее, если это ОЧЕНЬ важно, чем вы, вероятно, в конечном итоге создадите инструменты или какое-то наложение на панель инструментов для поддержки вашей команды, в какой момент вы действительно хочу тот, с лучшим API. Я не пробовал Jenkins API, поэтому я не могу сравнить, хотя TC API должен дать вам то, что вам нужно.

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

Как правило, это довольно быстро, чтобы выполнить то, что вы хотите, и квази API взаимодействия с журналом - очень хорошая функция, если вы выполняете много пользовательских сценариев в своем конвейере.

Дженкинс:

Битва проверена и обширна.

Но он несколько менее симпатичен, не говоря уже о том, что он некрасив, хотя можно сказать, что функциональность важнее внешнего вида.

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

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

Я обнаружил, что и то, и другое одинаково быстро для начала, хотя с Jenkins вам, возможно, нужно быть более динамичным с плагинами, чем с TeamCity. Так что, если у вас плотный ИТ-отдел и вы не получите административного доступа к серверу, это может стать проблемой. Усугубляется гораздо более быстрый цикл выпуска, чем TeamCity (еженедельно).

Я обнаружил, что Дженкинс поддерживает больше парадигм цикла выпуска, чем TeamCity. Может быть проще найти шаблон процесса из коробки, который будет ближе к тому, что вы имеете в виду. Я говорю это с резервами, так как я не работал с TeamCity уже 2 года.

Я лично предпочитаю Jenkins в основном потому, что я склонен к Open Source для таких инструментов, и в меньшей степени, потому что я обнаружил, что его структура и механизм конфигурации больше согласны со мной.

YMMV

В целом, пользовательский опыт довольно похож. TeamCity имеет более симпатичный пользовательский интерфейс, но не особенно прост в использовании. С точки зрения функциональности, оба они фактически эквивалентны. Большая часть терминологии такая же.

Однако экосистемы плагинов довольно разные; Вы определенно захотите посмотреть, какие плагины доступны для TeamCity для достижения того, что вы пытаетесь сделать, поскольку это, вероятно, будет самой большой проблемой в плане перехода. Если вы привыкли запускать определенные плагины Jenkins, вам необходимо узнать: а) какие функциональные возможности предоставляет TeamCity без каких-либо необходимых плагинов и б) какие плагины доступны для добавления оставшихся функциональных возможностей и чем они отличаются от плагинов, которые вы используете? Привыкли в Дженкинс.

Я согласен с Адрианом по большинству пунктов. Пользовательский интерфейс TeamCity определенно красивее, и вы получаете намного больше встроенных функций из коробки с TeamCity, чем с Jenkins. Но Jenkins имеет открытый исходный код, и хотя качество (и документация) сильно варьируется от плагина к плагину, экосистема обширна.

Я использую Jenkins в течение многих лет и только недавно начал использовать TeamCity. Например, настройка зависимых заданий намного проще и интуитивнее в Jenkins, чем в TeamCity.