О TeamCity

Люблю я JetBrains. Их продукты. Видно, что программисты программировали для программистов. Получается чертовски удобно. И даже иногда не жалко за это заплатить.

Сегодня я не про IntelliJ IDEA, а про TeamCity. Сразу говорю, что до 20 конфигураций сборки и до 3 агентов это чудо бесплатно. Чего, в общем-то, для одного проекта среднего размера даже достаточно.

TeamCity — это инструмент Continuous Integration. Как и Jenkins (который форк Hudson). К сожалению, Jenkins — единственный открытый CI. Попробую рассказать, чем закрытый TeamCity может быть лучше.

Я несколько лет использовал Jenkins. А тут пару месяцев наслаждаюсь TeamCity.

Первое, чем хвастаются JetBrains — это поддержка различных систем сборки. Действительно, Jenkins нам предлагает или сборку Maven проекта, или написать скрипт (на Bash, Ruby, Python, чем угодно), который сделает все, что вам нужно.

TeamCity же предлагает солидный выбор сборщиков. От того же Maven и Ant, до прямой сборки проектов IntelliJ IDEA, Xcode или солюшенов Visual Studio. Интеграция со сборщиком означает не просто легкую его конфигурацию, но и «понимание» со стороны TeamCity хода сборки, что выражается в правильном учете времени сборки, и его прогнозировании, и потрясающей визуализации журнала сборки, с подсветкой ошибок и фолдингом.

Для Jenkins система контроля версий вашего кода, это лишь некий URL, где можно мониторить изменения, и запускать сборку, если надо. Ну еще можно показать список коммитов, которые попали в данную сборку.

TeamCity знает о вашем коде гораздо больше. Работа с VCS происходит независимо от сборок. TeamCity наблюдает за ветками, сразу за всеми ветками, за которыми нужно, в репозитории и ведет учет всех изменений. Можно посмотреть весьма приятные на вид диффы. Ну а если с данным репозиторием (и ветками) связан какой-то проект, то еще и видно, в какие билды вошли изменения. И наоборот: какие изменения вошли в билды.

Эта работа с репозиториями происходит на самом сервере TeamCity, агенты сборки тут не задействованы. Передача исходников на агент сборки может проходить двумя способами. Либо на агенте уже есть настроенная рабочая копия или клон репозитория, и TeamCity будет обновлять эту рабочую копию до нужной версии для сборки. Именно так и только так умеет работать Jenkins. А можно не заморачиваться настройкой VCS на агентах, TeamCity сервер закачает все исходники на агента самостоятельно. Иногда это может быть полезно.

В Jenkins, по крайней мере без сторонних плугинов, мы имеем дело с плоским списком проектов. И в лучшем случае мы можем создавать новые проекты на основе существующих. Или запускать сборку другого проекта в зависимости от сборки другого. Каждый проект — это длииинююющий список настроек: от настроек системы контроля версий до post-build action.

В TeamCity все сложнее и мощнее. Проекты организуют дерево, с полноценным наследованием многочисленных параметров и целых секций конфигурации. Настройки систем контроля версий и конфигураций сборки — раздельны. Одна конфигурация сборки прекрасно собирает все ветки исходного кода, находящиеся под наблюдением. Что на самом деле чертовски удобно. Определяете один стандарный способ сборки проекта, указываете, какие ветки нужно собирать, и пожалуйста, получаете свежие сборки и артефакты каждой интересующей ветки.

Сами конфигурации сборки могут быть созданы на основе шаблонов. Опять таки с полноценным наследованием. Можно описать сборку в общих чертах, с кучей параметров в тех местах, где что-то может меняться. А подставлять параметры можно вообще куда угодно, хоть в скрипты. А потом, на основе шаблона, создать уже конкретную конфигурацию сборки. И TeamCity проследит, чтобы все упомянутые параметры были определены. А если что-то нужно поменять в шаблоне, это повлияет на все созданные по шаблону сборки. Я же говорю, полноценное наследование.

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

TeamCity устроен посложнее. Cервер тут такое же веб-приложение на Java. Но есть и полноценные агенты в виде демонов/сервисов, которые нужно устанавливать и немножко настраивать. Иногда это усложняет жизнь в плане всяких файерволов и маршрутизации.

Строго говоря, TeamCity не делает ничего такого, чего не мог бы сделать Jenkins. Но в TeamCity проще настраивать сборки, проще создавать похожие сборки, нагляднее видеть, что происходит, им приятнее пользоваться. Сильно проще и сильно приятнее.