Люблю я JetBrains. Їх продукти. Видно, що програмісти програмували для програмістів. Виходить біса зручно. І навіть іноді не шкода за це заплатити.
Сьогодні я не про IntelliJ IDEA, а про TeamCity . Відразу кажу, що до 20 конфігурацій збірки і до 3 агентів це чудо безкоштовно. Чого, в общем-то, для одного проекту середнього розміру навіть досить.
Я кілька років використовував 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 простіше налаштовувати збірки, простіше створювати схожі збірки, наочніше бачити, що відбувається, їм приємніше користуватися. Сильно простіше і сильно приємніше.
