Підтримувані платформи та середовища

Платформи (операційні системи)

Веб-браузери

Веб-інтерфейс TeamCity в основному сумісний з W3C, тому майже будь-який сучасний браузер повинен добре працювати з TeamCity. Наступні браузери були спеціально протестовані і повідомили, що працюють належним чином в останніх версіях:

• Google Chrome

• Mozilla Firefox

• Сафарі під Mac

• Microsoft Edge

• Microsoft Internet Explorer 11+. Підтримка Internet Explorer 10 припиняється з teamcity 2018.1.4.

• Опера 15+

Побудувати бігунів

TeamCity підтримує широкий спектр інструментів збірки, що дозволяє як командам програмного забезпечення Java, так і .NET створювати свої проекти.

Рамки тестування

• JUnit 3.8.1+, 4.x

• Підтримуються NUnit 2.2.10, 2.4.x, 2.5.x, 2.6.x, 3.0.x (виділений бігун збірки).

• TestNG 5.3+

• MSTest 8.x-12.x,14.x, 15.x, 19.x і VSTest підтримуються бігуном тестів Visual Studio; вимагає відповідного випуску Microsoft Visual Studio або Visual Studio тест-агент інстальовано на побудувати агента.

• MSpec (вимагає MSpec, встановленого на агенті збірки)

Системи керування версіями

• Git (для автоматичної git gc підтримки потрібен клієнт Git, встановлений на сервері, щоб виконати обслуговування клонів Git, рекомендується остання версія)

• Підривна діяльність (серверні версії 1.4-1.9 і вище, якщо протокол зворотно сумісний).

• Perforce (потрібен клієнт Perforce, встановлений на сервері TeamCity). Перевірте проблеми сумісності.

• Perforce (потрібен клієнт Perforce, встановлений на сервері TeamCity). Перевірте проблеми сумісності.

• Підтримується Team Foundation Server 2005, 2008, 2010, 2012, 2013, 2015, 2017.

• Mercurial (потрібен клієнт Mercurial "hg" v1.5.2+, встановлений на сервері)

• CVS

• SourceGear Vault 6 і 7 (потрібні клієнтські бібліотеки командного рядка Vault, встановлені на сервері TeamCity), інтегровані через додатковий плагін

• Borland StarTeam 6 і новіших версій (клієнтський додаток StarTeam повинен бути встановлений на сервері TeamCity)

• IBM Rational ClearCase Base і UCM режими (вимагає клієнт ClearCase встановлений і налаштований на сервері TeamCity), інтегрований за допомогою додаткового плагіна

• Microsoft Visual SourceSafe 6 і 2005 (потрібен клієнт SourceSafe, встановлений на сервері TeamCity, доступний тільки на платформах Windows)

Для підтримки інших VCS, будь ласка, перевірте зовнішні плагіни доступні.

Інтеграція хмарних агентів

• Амазонка EC2
• VMWare vSphere

Дивіться також детальну інформацію про хмарні інтеграції та плагіни інтеграції хмар без комплекту та сторонніх розробників хмарних інтеграцій.

Інтеграція послуг хостингу VCS

• GitHub / GitHub Enterprise
• GitLab
• Хмара бітбакета

• Azure DevOps Services або раніше Visual Studio Team Services

Інтеграція відстеження проблем

• JetBrains YouTrack 1.0 і пізніших версій (протестований з останньою версією)

• Atlassian Jira 4.4 і пізніших версій (всі основні функції також, як повідомляється, працювали для версії 4.2)

• Bugzilla 3.0 і пізніших версій (протестований з Bugzilla 5.0.1)

• GitHub
• Бітбакет

• Azure DevOps Server (раніше Visual Studio team Foundation Server – підтримується версія 2012 або пізнішої версії, і Azure DevOps services підтримуються)

Додаткові вимоги перераховані в інтеграції TeamCity з відстеженням проблем.

Посилання на проблеми будь-якого трекера проблем також можуть бути розпізнані в коментарях до змін за допомогою зіставлення зовнішніх посилань у коментарях.

Інтеграція IDE

TeamCity надає плагіни продуктивності для наступних ВПО:

• Eclipse: Підтримуються версії Eclipse 3.8 і 4.2-4.6. Затемнення має бути запущено під JDK 1.5+

• Плагін платформи IntelliJ: сумісний з IntelliJ IDEA 15.0.x - 2019.3.x (випуски Ultimate та Community); а також інші ВПО на основі тієї ж версії платформи, включаючи JetBrains RubyMine 6.3+, JetBrains PyCharm 3.1+, JetBrains PhpStorm/WebStorm 7.1+, AppCode 2.1+. Докладніше про сумісність можна дізнатися більше.

• Microsoft Visual Studio 2010, 2012, 2013, 2015, 2017 підтримується TeamCity Visual Studio надбудова поставляється як частина ReSharper Ultimate. Інстальовано .NET Framework обов'язковий.

Підтримувані бази даних

Докладніше про настроювання зовнішньої бази даних

• HSQLDB 2.3.2
  Внутрішня база даних відповідає лише цілям оцінки; ми настійно рекомендуємо використовувати зовнішню базу даних у виробничому середовищі.

• MySQL 5.0.33+, 5.1.49+, 5.5+, 5.6+, 5.7+, 8+ (Зауважте, що через помилки в MySQL версії 5.0.20, 5.0.22 та 5.1 до 5.1.48 не сумісні з TeamCity)

• Microsoft SQL Server 2005 або пізнішої версії (включно з експрес-виданнями), SQL Azure; Підтримка з'єднань SSL може потребувати цих оновлень.

• PostgreSQL 8.2 і новіших версій

• Oracle 10g і новіше (TeamCity тестується з драйвером  версії 12.1.0.1)

Оцініть вимоги до обладнання для TeamCity

Вимоги до обладнання відрізняються для сервера та агентів.

Вимоги до обладнання агента  в основному визначаються збірками, які виконуються. Запущене програмне забезпечення агента TeamCity вводить вимогу до додаткового часу процесора (але зазвичай ним можна нехтувати в порівнянні з вимогами процесора процесу збірки) і додаткової пам'яті: близько 500 Мб. Необхідний дисковий простір відповідає використанню диска збірками, запущеними на агенті (джерела оформлення замовлення, завантажені артефакти, дисковий простір, споживаний під час збірки; все, що об'єднано для регулярно відбуваються збірки). Хоча ви можете запустити агент збірки на тому ж комп'ютері, що і сервер TeamCity, рекомендований підхід полягає у використанні окремої машини (вона може бути віртуальною) для кожного агента збірки. Якщо ви вирішили інсталювати кілька агентів на одному комп'ютері, розгляньте можливі вузькі місця процесора, диска, пам'яті або мережі, які можуть виникнути. Функція побудови монітора  продуктивності може допомогти вам у аналізі даних у реальному часі.

Вимоги до серверного обладнання залежать від навантаження на сервер, що, в свою чергу, значно залежить від типу збірок і використання сервера. Розгляньмо наступні загальні вказівки.

Примітка до бази даних:Коли
широко використовуючи сервер, продуктивність бази даних починає відігравати більшу роль.
З міркувань надійності та продуктивності слід використовувати зовнішню базу даних.
Перегляньте примітки щодо вибору зовнішньої бази даних.
Вимоги до розміру бази даних, природно, варіюються залежно від обсягу збережених даних (кількість збірок, кількість тестів тощо). Активне використання бази даних сервера можна оцінити в декількох гігабайтах даних на рік.

Огляд використання апаратних ресурсів TeamCity:

• Процесор: TeamCity використовує кілька ядер процесора, тому збільшення кількості ядер має сенс. Для нетривіального використання TeamCity рекомендується принаймні 4 ядра процесора.

• Пам'ять: використовується основним процесом сервера TeamCity та дочірніми процесами (використовується для інтеграції Maven, інтеграції керування версіями, виконання Kotlin DSL). Перегляньте примітки щодо основного використання пам'яті процесу. Як правило, вам, ймовірно, не потрібно буде присвячувати більше 4G пам'яті серверу TeamCity, якщо ви не плануєте запускати більше 100 одночасних збірок (агентів), підтримувати більше 200 онлайн-користувачів або працювати з великими репозиторіями.

• Використання жорсткого диска / диска: Це підсумовується в основному з використання тимчасових каталогів (<TeamCity Home >/tempі каталогу часу за замовчуванням ОС) і  <TeamCity Data Directory>/systemвикористання. Продуктивність сервера TeamCity сильно залежить від продуктивності дискової системи. Оскільки TeamCity зберігає великі обсяги даних під >/system<TeamCity Data Directory (в першу чергу, кеш-пам'яті VCS і результати збірки), важливо, щоб доступ до диска був швидким (зокрема, читання / запис файлів у декількох потоках, перерахування файлів з атрибутами). Забезпечення хорошої продуктивності диска особливо важливо, якщо ви плануєте зберігати каталог даних на мережевому диску. Рекомендується використовувати локальне сховище для каталогу TeamCity Data Directory/system/caches . Дивіться також Каталог даних TeamCity.

• Мережа: Це в основному підсумовується від трафіку від серверів VCS, до клієнтів (веб-браузери, IDE і т.д.) і / від агентів збірки (відправляти джерела, отримувати результати збірки, журнали та артефакти).

Навантаження на сервер залежить від:

• кількість конфігурацій збірки;

• кількість збірок в історії;

• кількість збірок, що виконуються щодня;

• кількість даних, що споживаються і виробляються збірками (розмір використаних джерел і артефактів, розмір журналу збірки, кількість і розмір виводу модульних тестів, кількість перевірок і дублікатів показів, розмір і кількість вироблених артефактів і так далі);

• настроєні правила очищення

• кількість агентів та відсоток їх утилізації;

• кількість користувачів, які мають відкриті веб-сторінки TeamCity;

• кількість користувачів, які ввійшли з плагіна IDE;

• кількість і тип коренів VCS, а також налаштована перевірка інтервалу змін для коренів VCS. Режим оформлення замовлення VCS також актуальний: режим оформлення замовлення сервера генерує більше навантаження на сервер. Конкретні типи VCS також впливають на навантаження на сервер, але їх можна приблизно оцінити на основі продуктивності клієнта VCS;

• кількість змін, виявлених TeamCity за день у всіх коренях VCS;

• розмір репозиторію, з якими працює TeamCity;

• загальний розмір джерел, перевірених TeamCity щодня.

Загальним прикладом конфігурації обладнання, здатного обробляти до 100 одночасно запущених збірок і запущених тільки сервер TeamCity може бути:
Сервер підходить сучасний багатоядерний процесор, 8 Гб пам'яті, швидке підключення до мережі, швидкий і надійний жорсткий диск, швидкий зовнішній доступ до бази даних.

Виходячи з нашого досвіду, скромне обладнання, таке як двоядерний процесорIntel 3.2 ГГц, 3.2Gb пам'яті під Windows, мережевий адаптер 1Gb, один жорсткий диск, один ЖОРСТКИЙ ДИСК забезпечують прийнятну продуктивність для наступної установки:

• 60 проектів і 300 конфігурацій збірки (один з них активний і працює регулярно);

• більше 300 будівель на день;

• близько 2 Мб журналу на збірку;

• 50 будівельних агентів;

• 50 користувачів Інтернету та 30 користувачів IDE;

• 100 коренів VCS (в основному Perforce і Subversion за допомогою перевірки сервера), середня перевірка інтервалу змін становить 120 секунд;

• більше 150 змін на день;

• Kotlin DSL не використовується;

• база даних (MySQL) працює на одній машині;

• Процес сервера TeamCity має -Xmx1100m налаштування JVM.

Наступна конфігурація може забезпечити прийнятну продуктивність для більш завантаженого сервера TeamCity:Intel
Процесор Xeon E5520 2,2 ГГц (4 ядра, 8 потоків), 12 Гб пам'яті під Windows Server 2008 R2 x64, мережевий адаптер 1 Гб, 3 диски HDD RAID1 (загальні, один для артефактів, журналів і кеш-пам'яті, і один для зберігання бази даних)

Характеристики завантаження сервера:

• 150 проектів і 1500 конфігурацій збірки (третина з яких активна і працює регулярно);

• більше 1500 будівель на день;

• близько 4 Мб журналу на збірку;

• 100 будівельних агентів;

• 150 користувачів Інтернету та 40 користувачів IDE;

• 250 коренів VCS (в основному Git, Hg, Perforce і Subversion за допомогою агентської каси), середня перевірка інтервалу змін становить 180 секунд;

• більше 1000 змін на день;

• база даних (MySQL) працює на одній машині;

• Процес сервера TeamCity має -Xmx3700m налаштування x64 JVM.

Однак для того, щоб максимальне навантаження можна було добре впоратися, рекомендується більш потужне обладнання.

Вимоги до вільного простору на жорсткому диску в основному визначаються кількістю збірок, що зберігаються на сервері, і розміром артефактів / розміром журналу збірки в кожному. Сховище дисків сервера також використовується для зберігання кешів, пов'язаних з VCS, і ви можете оцінити, що вдвічі перевищує розмір оформлення замовлення всіх коренів VCS, налаштованих на сервері.

Якщо збірки генерують велику кількість даних (артефакти / побудувати журнал / тест даних), рекомендується використовувати швидкий жорсткий диск для зберігання .BuildServer/system каталогів і швидкої мережі між агентами і сервером.

Загальна рекомендація щодо розгортання великомасштабної установки TeamCity полягає в тому, щоб почати з розумного обладнання при розгляді оновлення апаратного забезпечення. Потім збільшуйте навантаження на сервер (наприклад, поступово додавайте більше проектів), відстежуючи характеристики продуктивності та приймаючи рішення про необхідні вдосконалення апаратного або програмного забезпечення. Існує також еталонний плагін , який можна використовувати для оцінки кількості одночасного складання поточної установки сервера може впоратися. У будь-якому випадку, кращі методи адміністрування рекомендуються, як збереження адекватного рівня дефрагментації диска, і так далі.

Починаючи з адекватно завантаженої системи, якщо потім збільшити кількість одночасно запущених збірок (агентів) в якийсь момент, будьте готові збільшити швидкість доступу до процесора, бази даних і жорсткого диска, обсяг пам'яті на той же фактор для досягнення тієї ж продуктивності.
Якщо ви збільшуєте кількість збірок в день, будьте готові збільшити розмір диска.

Якщо ви розглядаєте хмарне розгортання для агентів TeamCity (наприклад, на Amazon EC2), також перегляньте налаштування TeamCity для Amazon EC2

Примітка про налаштування агентів у внутрішній установці TeamCity JetBrains: Ми використовуємо як окремі машини, кожна з яких працює під управлінням одного агента, так і виділені "сервери", що працюють під управлінням декількох віртуальних машин, кожна з яких має один агент встановлений. Експериментуючи з апаратним і програмним забезпеченням, ми зупинилися на конфігурації, коли кожна фізична машина core7i працює під управлінням 3 віртуальних агентів, кожен з яких використовує окремий жорсткий диск. Це пов'язано з тим, що наші (в основному Java) збірки залежать від продуктивності жорсткого диска в першу чергу. Але YMMV.

TeamCity, як відомо, добре працює з 500+ будівельними агентами (500 одночасно запущених збірок активно реєструє дані про час виконання збірки). У синтетичних тестах сервер функціонував нормально з цілих 1000 одночасних збірок (сервер з 8 ядрами, 32 Гб загальної пам'яті, що працює під Linux, і сервер MySQL, що працює на окремій порівнянній машині). Навантаження на сервер, що виробляється кожною збіркою, залежить від обсягу даних, які виробляє збірка (журнал збірки, номер тестів та деталі несправностей, номери випусків інспекцій / дублікатів тощо). Збереження обсягу даних обґрунтовано обмеженим (публікація великих виходів як артефактів збірки, а не друк їх у стандартному виході; налаштування профілів інспекції для повідомлення про обмежений набір найважливіших інспекційних звернень тощо) допоможе масштабувати сервер для обробки більш одночасних збірок.
Якщо вам потрібно набагато більше агентів / паралельних збірок, рекомендується використовувати налаштування декількох вузлів. Якщо потрібна істотно велика кількість агентів, рекомендується розглянути можливість використання декількох окремих екземплярів TeamCity і розподілу проектів між ними. Ми постійно працюємо над підвищенням продуктивності TeamCity і готові тісно співпрацювати з організаціями, що працюють на великих установках TeamCity, щоб вивчити будь-які проблеми з продуктивністю та покращити TeamCity для обробки більших навантажень.