Live-данные · обновлено 7 сентября 2026 г.
TeamCity
TeamCity — CI/CD-сервер от JetBrains: он забирает код из репозитория, собирает его на агентах, прогоняет тесты и доводит изменение до артефакта или деплоя. Фирменные черты — цепочки сборок со снапшот-зависимостями и конфигурация как код на Kotlin DSL.
Автор·Мурадов Юрий·Аналитик SkillStatКВПроверено·Кузнецов Вячеслав·Технический редактор·DevOps/SRE-техлид · опыт 10+ лет
Вакансий
36
активных в Москве
Медиана зарплаты
—
Индекс спроса
27/100
#209 из 286 навыков
Доля IT-рынка
0.7%
8 профессий
Коротко о навыке
TeamCity — CI/CD-сервер от JetBrains. Схема классическая: сервер хранит конфигурации сборок, следит за репозиториями и управляет очередью, а сами сборки выполняют агенты — отдельные машины или контейнеры. Фирменные черты — build chains (цепочки сборок со снапшот-зависимостями, где компиляция, тесты и деплой связаны в конвейер и переиспользуют результаты друг друга) и Kotlin DSL, позволяющий держать всю конфигурацию сервера как код в репозитории и проводить изменения CI через ревью.
На рынке TeamCity — навык-спутник: его почти никогда не требуют изолированно, он идёт в связке с Git, Docker, сборщиками и тестовыми фреймворками. Доминирующая роль — DevOps-инженер, следом идут тестировщики (и ручные, и автоматизаторы) и Java-разработчики: исторически TeamCity силён именно в Java/Kotlin-командах и там, где уже живёт стек JetBrains. Главные альтернативы — Jenkins, GitLab CI и GitHub Actions; выбор между ними — один из типовых вопросов на собеседовании.
Для этого навыка доступны ограниченные данные (менее 50 вакансий или нет зарплатных данных). Аналитика носит ориентировочный характер.
Что такое Teamcity
Кто использует
Прежде всего DevOps-инженеры; также тестировщики, Java-разработчики и мобильные команды — все, кому нужен управляемый конвейер сборки и тестов.
Позиция на рынке
Заметный, но не самый массовый CI-инструмент: конкурирует с Jenkins, GitLab CI и GitHub Actions, особенно силён в Java/Kotlin-командах и корпоративных установках.
Что такое TeamCity
TeamCity — сервер непрерывной интеграции и доставки: он автоматически забирает код из репозитория после каждого изменения, собирает его, прогоняет тесты и публикует результат — jar-файл, Docker-образ, установщик. Без такого сервера каждый разработчик собирает проект у себя, тесты запускаются «когда вспомнили», а ошибки интеграции всплывают перед релизом. TeamCity превращает это в конвейер: любое изменение проходит одинаковый, воспроизводимый путь от коммита до артефакта, и команда сразу видит, что сломалось и кем.
Сервер, агенты и очередь
Архитектура разделена на две части. Сервер — мозг: хранит конфигурации сборок, следит за репозиториями, показывает результаты и управляет очередью. Агенты — рабочие руки: отдельные машины, виртуалки или контейнеры, которые получают задание, выкачивают код и выполняют шаги сборки. Когда сборка попадает в очередь, сервер подбирает агент по требованиям: сборке iOS нужен агент на macOS с Xcode, Java-сервису — агент с нужным JDK. Такое разделение позволяет масштабировать конвейер добавлением агентов и держать разные окружения в одном пуле.
Build chains: конвейер из сборок
Вместо одной гигантской сборки «собери всё» TeamCity предлагает цепочки: отдельные конфигурации для компиляции, тестов и деплоя связываются снапшот-зависимостями. Снапшот-зависимость гарантирует, что вся цепочка работает на одном и том же наборе ревизий исходников — тесты проверяют ровно тот код, который был собран. Уже собранные части не пересобираются, независимые звенья идут параллельно на разных агентах, а при падении перезапускается только нужное звено. Это главный аргумент TeamCity в сложных конвейерах.
Понятия / Карта
Из чего состоит Teamcity
Понятие Что это Что нужно уметь
Конфигурация сборки
Рецепт одной сборки: откуда брать код, какие шаги выполнять, что получить на выходе.
Проектировать конфигурации с шаблонами и параметрами, а не плодить копии под каждый проект.
Агент сборки
Машина или контейнер, которые выполняют сборку по заданию сервера.
Настраивать требования к агентам, держать окружение чистым, масштабировать пул под нагрузку.
Build chain
Несколько сборок, связанных в конвейер: компиляция, тесты, деплой.
Строить снапшот-зависимости, распараллеливать звенья и переиспользовать готовые результаты.
Kotlin DSL
Описание настроек сервера кодом, который лежит в репозитории.
Вести конфигурацию через versioned settings, проводить изменения CI через ревью и откаты.
Артефакты
Файлы-результаты сборки: jar, образ, отчёт — сервер их хранит и передаёт дальше.
Писать правила публикации и настраивать зависимости артефактов между сборками цепочки.
VCS root и триггеры
Подключение репозитория и правила, по которым сборка стартует сама.
Настраивать фильтры веток, чекаут-правила, триггеры по изменениям и расписанию.
Механика / Работа
Как устроен конвейер в TeamCity
Путь изменения от коммита до развёрнутой версии — через очередь, агентов и цепочку сборок.
Шаг Слой Смысл
Шаг 01
Триггер ставит сборку в очередь
Сервер следит за репозиторием: новое изменение по фильтру веток запускает сборку. Очередью управляет сервер — он же подбирает агент, подходящий под требования конфигурации.
Шаг 02
Агент выполняет шаги
Агент выкачивает код и проходит шаги конфигурации: компиляция, тесты, анализ. Результаты тестов сервер разбирает на лету — история каждого теста и виновное изменение видны сразу.
Шаг 03
Цепочка доводит до релиза
Снапшот-зависимости связывают сборки в конвейер: артефакты передаются дальше, независимые звенья идут параллельно, и изменение доезжает до деплоя без пересборок и ручных шагов.
Карьера / Роли
Кому нужен Teamcity
Teamcity переносится между ролями: DevOps-инженер, Ручной тестировщик, Java-разработчик. В одном треке этот навык может быть основным рабочим инструментом, а в другом - сильным прикладным усилителем основной специализации.
Роли с Teamcity за период
DevOps-инженер — самый заметный профиль в распределении ролей по навыку.
Роль Упоминаний за период Медиана
Текущий срез показывает активные вакансии сейчас. Распределение по ролям рассчитано по расширенной исторической выборке, поэтому значения могут быть выше текущего количества активных вакансий.
Практика / Задачи
Частые задачи с Teamcity
Teamcity ценен не абстрактным знанием инструмента, а повторяющимися рабочими задачами — ниже они разобраны так, как встречаются в реальной работе.
# Задача Что делает специалист
Задача 01
Первая конфигурация на Kotlin DSL
Сборка проекта с автозапуском по изменениям в репозитории — конфигурация описана кодом.
import jetbrains.buildServer.configs.kotlin.*
import jetbrains.buildServer.configs.kotlin.buildSteps.script
import jetbrains.buildServer.configs.kotlin.triggers.vcs
object Build : BuildType({
name = "Build and Test"
vcs {
root(DslContext.settingsRoot)
}
steps {
script {
name = "Сборка и тесты"
scriptContent = "./gradlew clean build"
}
}
triggers {
vcs {
branchFilter = "+:main\n+:feature/*"
}
}
})
Задача 02
Цепочка со снапшот-зависимостью
Деплой стартует только после успешной сборки — и на том же наборе ревизий исходников.
object Deploy : BuildType({
name = "Deploy"
dependencies {
snapshot(Build) {
onDependencyFailure = FailureAction.FAIL_TO_START
}
artifacts(Build) {
artifactRules = "build/libs/app.jar => app/"
}
}
// цепочка Build -> Deploy: Deploy не пересобирает код,
// а получает готовый артефакт из Build
})
Задача 03
Публикация артефактов
Правила описывают, какие файлы сервер сохранит после сборки и передаст дальше по цепочке.
object Package : BuildType({
name = "Package"
// что сохранить после сборки:
artifactRules = "build/libs/*.jar => binaries/\nbuild/reports/** => reports.zip"
steps {
script {
name = "Собрать jar"
scriptContent = "./gradlew jar"
}
}
})
Задача 04
Тесты с историей падений
TeamCity сам разбирает результаты JUnit/TestNG: история каждого теста, «мигающие» тесты, расследования.
import jetbrains.buildServer.configs.kotlin.buildSteps.maven
steps {
maven {
goals = "clean test"
runnerArgs = "-Dmaven.test.failure.ignore=true"
}
}
failureConditions {
testFailure = true
// сборка падает при упавших тестах,
// но TeamCity успевает собрать все результаты
}
Задача 05
Требования к агентам и секреты
Сборка попадёт только на подходящий агент; пароль хранится как защищённый параметр и маскируется в логах.
object BuildIos : BuildType({
name = "iOS Build"
params {
param("env.CONFIGURATION", "Release")
password("env.API_TOKEN", "credentialsJSON:xxxx")
}
requirements {
contains("teamcity.agent.jvm.os.name", "Mac OS X")
exists("env.XCODE_HOME")
}
})
Задача 06
Сборка Docker-образа
Типовой шаг доставки: собрать образ, пометить номером сборки TeamCity и отправить в реестр.
steps {
script {
name = "Собрать и отправить образ"
scriptContent = "docker build -t registry.local/app:%build.number% .\ndocker push registry.local/app:%build.number%"
}
}
// %build.number% — встроенный параметр TeamCity,
// подставляется при запуске сборкиПрактика / Ошибки
Ошибки новичков
Ошибка 01
Настраивать всё мышкой
Конфигурация, накликанная в интерфейсе, не версионируется: кто, что и когда поменял — неизвестно, откат мучителен, перенос на новый проект — вручную по памяти. Kotlin DSL решает это архитектурно; вести серьёзный конвейер без него — накапливать невоспроизводимость.
Ошибка 02
Одна гигантская сборка
Компиляция, все тесты и деплой одним списком шагов: сборка идёт часами, параллелить нечего, при падении последнего шага перезапускается всё. Правильный путь — разбить на конфигурации и связать в build chain со снапшот-зависимостями.
Ошибка 03
Секреты открытым текстом
Токены и пароли в обычных параметрах или прямо в скриптах утекают в логи сборок и в историю DSL-репозитория. Для секретов есть параметры типа password и интеграции с внешними хранилищами — маскировка в логах и шифрование из коробки.
Ошибка 04
Грязные агенты
Сборка, которая проходит только потому, что на агенте остались кэши и файлы от прошлых запусков, — мина замедленного действия: на новом агенте она развалится. Лечится чистым чекаутом, контейнерными сборками и периодической проверкой на «пустом» агенте.
Ошибка 05
Привыкнуть к красному
Когда «мигающие» тесты падают через раз, команда перестаёт реагировать на статус сборки — и пропускает настоящие поломки. В TeamCity для этого есть расследования и муты: назначить ответственного, заглушить известную проблему с комментарием, но не игнорировать сигнал.
Рынок / Контекст
TeamCity в современных IT-проектах: контекст спроса
Ядро спроса на TeamCity — DevOps-инженеры: для них это один из инструментов конвейера наряду с Docker, Kubernetes и системами мониторинга. Вторая заметная группа — тестировщики, и ручные, и автоматизаторы: они не администрируют сервер, но ежедневно живут в его интерфейсе — запускают прогоны, разбирают упавшие тесты, следят за отчётами. Третья — Java-разработчики и смежные роли: TeamCity исторически силён в Java/Kotlin-экосистеме и командах на стеке JetBrains. Важно понимать: работодатель редко ищет «специалиста по TeamCity» — он ищет инженера, который понимает CI/CD как процесс, а конкретный сервер знает как инструмент. Поэтому TeamCity в резюме работает в связке с Git, Docker и сборщиками, а не отдельной строчкой.
Сокращает ручную работу
Teamcity востребован там, где инструмент реально ускоряет повторяемые задачи команды, а не существует отдельной теорией.
Встроен в рабочий процесс
Спрос держится дольше, когда навык нужен не эпизодически, а как часть ежедневного цикла разработки, проверки или доставки.
Закреплён в зрелом стеке
Teamcity чаще ищут там, где процесс уже стандартизирован и без этого инструмента команда теряет скорость и предсказуемость.
Сигнал рынка
Стабильный спрос
Teamcity формирует устойчивый спрос внутри своего рабочего сегмента.
Рынок / Спрос
Спрос на Teamcity на рынке
Teamcity сохраняет устойчивый прикладной спрос на рынке: 36 активных вакансий, #209 по рынку, 0.7% IT-вакансий. Ниже показано число открытых вакансий на конец каждого месяца: это исторический ряд по состоянию на конец месяца, а не текущий срез рынка на сегодня.
Сила спроса
Стабильный спрос 36
активных вакансий сейчас
#209 по рынку • 0.7% IT-вакансий
Месяц к месяцу
63
сентябрь 2026 — предварительный накопительный срез
-15 вакансий и -19% к предыдущему месяцу.
Связи / Навыки
Навыки в связке с Teamcity
Teamcity редко живёт изолированно: чаще всего рынок видит его рядом с CI/CD, Docker, Java. Самая плотная связка сейчас - CI/CD: оба навыка встречаются вместе в 81% вакансий.
Главная связка: CI/CD • 81% вакансий. Показываем общерыночные связки Teamcity: не junior-минимум из блока выше, а навыки, которые чаще всего встречаются рядом с ним в одной вакансии.
Рабочий стек вокруг Teamcity
навыки, которые рынок чаще всего видит рядом в одной вакансии
Навык Зачем рядом Доля
Вход / Старт
Порог входа
Сейчас на рынке 2 активных junior-вакансий с Teamcity. Это 6.2% всех вакансий по навыку, поэтому для старта важнее всего смотреть на реальный объём junior-окна и на стек, который рынок ждёт рядом.
Junior-вакансии сейчас
2
активных вакансий
6.2% всех вакансий по навыку • Senior / Junior 8.1x
Доля junior
6.2%
% всех вакансий по навыку
Окно входа узкое: рынок чаще нанимает с опытом.
Что нужно на старте
Стартовый стек
22
навыков в медианной вакансии
Медианная вакансия с Teamcity ожидает около 22 навыков в стеке. Это широкий стартовый набор: рынок обычно ищет не один изолированный инструмент, а рабочую комбинацию соседних навыков.
Чаще всего требуют вместе
навыки из junior-вакансий, где встречается Teamcity
Навык Junior-вакансии
Карьера / Резюме
Teamcity в резюме: что значит "знаю Teamcity"
Владение TeamCity в резюме — это не просто строчка, а демонстрация понимания CI/CD процессов. Что означает каждый уровень и что показать на собеседовании.
Уровень Что значит Что показать
Beginner
Знаю базовые понятия: сборки, агенты, триггеры.
Создал первую сборку, настроил простой CI пайплайн.
Junior developer
Могу настроить сборку Java/Kotlin проекта, работать с UI.
Сопровождал 1-2 проекта, настраивал тесты и артефакты.
Middle developer
Использую Kotlin DSL, управляю агентами, оптимизирую сборки.
Мигрировал проекты с UI на Kotlin DSL, настроил цепочки сборок.
QA automation
Настраиваю запуск тестов, интегрирую отчёты, анализирую падения.
Настроил параллельный запуск Selenium тестов, публикацию Allure.
Data/ML
Могу настроить сборку Docker-образов для ML моделей.
Настроил CI для тренировки моделей, сохранение весов как артефактов.
DevOps junior
Установил и настроил TeamCity, управляю агентами, базовые скрипты.
Развернул TeamCity на Linux, подключил 3 агента, настроил уведомления.
SRE/platform
Проектирую масштабируемую инфраструктуру, интегрирую с Kubernetes.
Спроектировал систему с 50 агентами, настроил SSO и аудит.
Сравнение / Инструменты
TeamCity в экосистеме
С какими инструментами TeamCity работает в реальных конвейерах.
Инструмент За что отвечает Когда нужен Граница
Kotlin DSL
Конфигурация сервера как код
Когда конвейеров много и изменения CI должны проходить ревью
Порог входа выше, чем у настройки в интерфейсе; код специфичен для TeamCity.
Docker
Изолированные окружения сборки и формат артефактов
Когда на общих агентах нужны разные окружения и доставка образами
Агентам нужен доступ к Docker и контроль места под образы и кэши.
Maven / Gradle
Сборщики, выполняющие шаги внутри конфигураций
Java/Kotlin-проекты — основная среда обитания TeamCity
Логика сборки живёт в сборщике; TeamCity управляет запуском, но не заменяет его.
Allure и тестовые отчёты
Наглядная отчётность поверх результатов автотестов
Когда QA-команде нужна детальная картина прогонов для разборов
Базовую историю тестов TeamCity ведёт сам — внешний отчёт нужен не всегда.
Argo CD / GitOps
Доставка в Kubernetes после CI
Когда деплой должен управляться желаемым состоянием кластера
TeamCity отдаёт проверенный образ, но синхронизацией кластера не занимается.
Навык / Применение
Где используется Teamcity
TeamCity применяется везде, где код должен превращаться в проверенный артефакт автоматически — от Java-бэкенда до мобильных сборок и корпоративных конвейеров.
Сценарий 01
CI для Java/Kotlin-бэкенда
Классическая ниша: сборка Maven/Gradle-проектов, юнит- и интеграционные тесты, публикация артефактов в репозиторий. Интеграция с IntelliJ IDEA — удалённый запуск и...
Сценарий 04
Сборка и доставка образов
Сборка Docker-образов, публикация в реестр, запуск деплой-шагов на тестовые и боевые окружения — TeamCity доводит изменение от коммита до развёрнутой версии.
По направлениям
Teamcity заметен в 3 направлениях рынка с долей выше 5%.
Направление Контекст Доля
Тестирование
Часть спроса по навыку сосредоточена в этом направлении.
47.1%
Инфраструктура
Деплой, Docker/K8s, конфигурация, масштабирование билд-агентов.
30.8%
Разработка
Java/Kotlin проекты, .NET, автоматическая сборка и тестирование.
19.2%
Безопасность
Часть спроса по навыку сосредоточена в этом направлении.
2.9%
Направления показывают, в каких частях IT-рынка навык заметен чаще всего, без разбивки по ролям.
Инструмент / Возможности
Что даёт TeamCity
Возможности, за которые TeamCity выбирают вместо конкурентов.
Build chains
Цепочки со снапшот-зависимостями: единый набор ревизий на весь конвейер, переиспользование результатов, параллельные звенья и перезапуск только упавшего звена.
Kotlin DSL
Конфигурация сервера как типизированный код в репозитории: ревью изменений CI, откаты через историю, автодополнение и проверка ошибок в IDE.
Интеллект по тестам
История каждого теста, детектор «мигающих», расследования с ответственными и муты известных проблем — падения разбираются, а не копятся.
Функциональность из коробки
VCS, сборщики, отчёты, уведомления и интеграция с IDE встроены и обновляются вместе с сервером — конвейер не рассыпается после обновления плагинов.
Сравнение / Контекст
TeamCity vs Jenkins vs GitLab CI
Три подхода к CI — критерии, по которым реально выбирают.
TeamCity vs Jenkins: стоимость владения
Главный критерий здесь — сколько команда готова вкладывать в поддержку самого CI. Jenkins бесплатен и гибок, но конвейер собирается из сотен плагинов, которые нужно подбирать, обновлять и чинить...
TeamCity vs GitLab CI: где живёт код
Если весь цикл разработки уже в GitLab, встроенный CI выигрывает связностью: конвейер, merge request и реестр образов в одном интерфейсе, отдельный сервер не нужен. TeamCity берут, когда репозитории...
TeamCity vs GitHub Actions: модель инфраструктуры
Actions запускает облачные раннеры на каждый прогон и берёт оплату минутами — для открытых и небольших проектов это старт без инфраструктуры вообще. TeamCity строится вокруг собственных постоянных...
Практика / Workflow
Как Teamcity используется в реальном проекте
Этап Что происходит Артефакт
1 Коммит
Разработчик отправляет изменение в репозиторий
Новая ревизия в VCS
2 Триггер
VCS-триггер ставит сборку в очередь
Сборка в очереди с набором ревизий
3 Назначение агента
Сервер подбирает агент по требованиям
Агент с чистым чекаутом кода
4 Сборка и тесты
Шаги: компиляция, тесты, анализ
Статус сборки и история тестов
5 Артефакты
Публикация файлов по правилам
Артефакты в хранилище сервера
6 Цепочка и деплой
Зависимые конфигурации подхватывают результат
Развёрнутая версия приложения
Инструмент / Оркестрация
TeamCity: запуск и настройка билд-агентов
TeamCity использует архитектуру «сервер — агенты». Сервер управляет проектами, очередью и историей, а агенты выполняют сборки. Это позволяет масштабировать инфраструктуру: добавил новый агент — увеличил пропускную способность.
Установка сервера (Docker)
TeamCity поставляется как Docker-образ jetbrains/teamcity-server. Запуск: docker run -d --name teamcity-server -p 8111:8111 -v /data/teamcity_server/datadir:/data/teamcity_server/datadir -v...
Подключение агентов
Агенты устанавливаются на отдельные машины или в контейнеры. Используйте образ jetbrains/teamcity-agent, укажите URL сервера и авторизационный токен. Агенты автоматически подключаются и готовы к...
Масштабирование агентов через Kubernetes
Запускайте агенты как поды в Kubernetes. TeamCity может динамически создавать и удалять агенты в зависимости от нагрузки. Используйте официальный helm-чарт или плагин.
Настройка VCS Root
Подключите репозиторий (Git, Mercurial, Perforce, SVN). Укажите URL, ветку и учётные данные. Один VCS Root можно использовать в нескольких конфигурациях сборки.
Создание Build Configuration
Определите шаги сборки (команды, скрипты, сборщики), триггеры (VCS, расписание), параметры и зависимости. Используйте шаблоны для переиспользования.
Настройка цепочек сборок (Build Chain)
Свяжите конфигурации так, чтобы артефакты одной передавались в другую. Например: сборка библиотеки → сборка сервиса → интеграционные тесты. Используйте Snapshot Dependency для точной версионности.
Практика / TeamCity
TeamCity: лучшие практики и ошибки новичков
Практика 01
Используйте шаблоны сборок
Создавайте шаблоны для стандартных типов сборок (Java, .NET, Node.js). Изменения в шаблоне автоматически применяются ко всем конфигурациям.
Практика 02
Параметризация конфигураций
Используйте параметры сборки для управления средами, версиями и учётными данными. Определяйте параметры на уровне проекта, конфигурации или конкретного запуска.
Практика 03
Храните конфигурации в VCS (Kotlin DSL)
Перенесите конфигурации TeamCity в Git с помощью Kotlin DSL. Версионируйте изменения, проводите code review, автоматически разворачивайте инфраструктуру.
Практика 04
Правила нейминга билдов
Называйте конфигурации осмысленно: ServiceA: Build, ServiceA: Unit Tests, ServiceA: Deploy Staging. Используйте папки для группировки.
Практика 05
Кэшируйте зависимости между сборками
Включите кэширование Maven/Gradle/npm зависимостей на агенте. Это ускоряет повторные сборки.
Практика 06
Настраивайте уведомления и отчёты
Интегрируйте TeamCity с Slack, Telegram или email. Настройте автоматическую отправку отчётов о стабильности тестов.
Практика 07
Регулярно чистите артефакты
Настройте политику хранения артефактов, чтобы не переполнить диск. TeamCity позволяет удалять старые сборки автоматически.
Практика 08
Используйте интроспекцию (Investigation)
Включите автоматическое назначение ответственного за упавший тест. TeamCity анализирует коммиты и находит автора изменений.
Практика / Безопасность
Безопасность Teamcity: что нельзя делать
Риск 01
Управление токенами доступа
Используйте персональные токены доступа (PAT) вместо паролей для агентов и интеграций. Храните токены в параметрах сборки типа 'password'.
Риск 02
SSL-сертификаты для агентов
Настройте HTTPS для сервера TeamCity, чтобы шифровать трафик между сервером и агентами. Используйте Let's Encrypt или корпоративный CA.
Риск 03
Изоляция агентов в Docker
Запускайте агенты в контейнерах, чтобы изолировать среды сборок. Для повышенной безопасности используйте запуск каждого билда в новом контейнере.
Риск 04
Аудит действий пользователей
Включите логирование всех действий (Audit Log) в настройках сервера. Регулярно проверяйте, кто и когда менял конфигурации.
Риск 05
Не используйте :latest образы для агентов
Пингуйте версии агентов, чтобы избежать неожиданных изменений. Используйте digest для критичных окружений.
Риск 06
Ограничьте права агентов
Не давайте агентам права root. Создайте отдельного пользователя с минимальными необходимыми правами.
Риск 07
Храните секреты в Vault
Для хранения паролей и ключей используйте HashiCorp Vault или аналоги. Интеграция с TeamCity через плагины.
Риск 08
Регулярно обновляйте TeamCity
Следите за обновлениями безопасности. JetBrains выпускает патчи, закрывающие уязвимости.
Риск 09
Сканируйте образы на уязвимости
Если используете Docker-образы агентов, проверяйте их на уязвимости с помощью Trivy или Grype.
Будущее / Роль
Перспективы Teamcity
Перспективы Teamcity завязаны не только на текущем спросе, но и на том, как навык встраивается в новые платформы, инструменты и рабочие контуры.
Сигнал 01
Конфигурация как код — норма
Индустрия окончательно уходит от настройки CI мышкой: конвейер описывается кодом, проходит ревью и живёт в репозитории. Kotlin DSL ставит TeamCity в этот тренд, и владение им...
Сигнал 02
Облачные варианты
JetBrains развивает облачные версии TeamCity: серверную часть можно не администрировать самим. Это снижает порог входа для небольших команд и смещает ценность специалиста от...
Сигнал 03
Давление встроенного CI
GitHub Actions и GitLab CI идут «в комплекте» с хостингом кода и забирают простые сценарии. TeamCity удерживает сложные корпоративные конвейеры, глубокую работу с тестами и...
Практика / Портфолио
Портфолио с Teamcity: с чего начать
Проект 01
CI-конвейер на Kotlin DSL
Взять свой пет-проект на Java или Kotlin и провести его от коммита до артефакта: сборка, тесты, публикация jar-файла — вся конфигурация в versioned settings, в репозитории рядом с кодом. Показывает и владение TeamCity,...
Проект 02
Build chain с параллельными тестами и деплоем
Цепочка из трёх-четырёх конфигураций: компиляция, параллельные пакеты тестов на разных агентах, сборка Docker-образа и деплой на тестовое окружение. Снапшот-зависимости, требования к агентам, секреты в защищённых...
Обучение / Маршрут
Как изучить Teamcity
TeamCity осваивается быстрее большинства инструментов DevOps-стека: первую рабочую сборку настраивают за вечер. Глубина приходит с Kotlin DSL, цепочками и эксплуатацией сервера в командах.
Этап Фокус Что изучать
Этап 01
База CI/CD
Понять сам процесс: зачем непрерывная интеграция, что такое конвейер, артефакт, окружение, чем CI отличается от CD. Без этого любые кнопки TeamCity —...
Этап 02
Сервер, агент, первая сборка
Поднять сервер и агент из официальных Docker-образов, подключить свой репозиторий и собрать проект: шаги, лог сборки, статус. Это даёт картину архитектуры...
Этап 03
Триггеры, параметры, артефакты
Автозапуск по изменениям в VCS и по расписанию, фильтры веток, параметры конфигурации, правила публикации артефактов. Ежедневный рабочий уровень.
Этап 04
Тесты и отчёты
Подключить запуск тестов, разобраться с историей падений, «мигающими» тестами, расследованиями и мутами. Это то, чем TeamCity выделяется на фоне...
Курсы · по данным рынка
Где учить TeamCity
Соответствие — доля тем навыка, которые охватывает программа курса
Практика / Первый запуск
Как начать изучать TeamCity
Три шага от пустого сервера до цепочки сборок на Kotlin DSL.
Шаг 01
Поднять сервер и агент
Официальные Docker-образы JetBrains поднимают сервер и агент за полчаса. Подключите свой пет-проект и соберите его: шаги, лог, статус — архитектура станет понятной на практике.
Шаг 02
Прогнать полный цикл
Добавьте VCS-триггер с фильтром веток, запуск тестов и публикацию артефактов. Сломайте тест намеренно и посмотрите, как TeamCity показывает историю падения и виновное изменение.
Шаг 03
Перевести в код и собрать цепочку
Включите versioned settings и опишите конфигурацию на Kotlin DSL, затем разбейте сборку на цепочку со снапшот-зависимостью. Эти два навыка отличают уверенного пользователя от новичка.
Старт / Документация
Официальные ресурсы и быстрый старт
Для инструментов вроде Teamcity на одной странице полезно держать и объяснение роли на рынке, и быстрые переходы к официальным ресурсам.
Частые вопросы
Вопросы и ответы
Что такое TeamCity простыми словами?
Это сервер, который автоматически собирает и тестирует код после каждого изменения в репозитории. Разработчик отправил коммит — TeamCity забрал код, собрал его на агенте, прогнал тесты и показал команде результат: зелёная сборка или конкретная ошибка с виновным изменением. Разработка идёт конвейером, а не ручными пересборками.
TeamCity или Jenkins — что выбрать?
Jenkins бесплатен и бесконечно гибок, но собирается из плагинов: их надо подбирать, обновлять и чинить. TeamCity даёт основную функциональность из коробки с продуманным интерфейсом, но на масштабе становится платным. Если есть кому постоянно ухаживать за Jenkins — он дешевле; если важнее предсказуемость и меньшая стоимость поддержки — TeamCity.
TeamCity бесплатный?
Частично. Версия Professional бесплатна и покрывает небольшую команду, но ограничена по числу конфигураций сборок и агентов. Дальше — платные лицензии на сервер и дополнительных агентов. Для обучения и пет-проектов бесплатной версии более чем достаточно.
Что такое Kotlin DSL в TeamCity?
Способ описать всю конфигурацию сервера кодом на Kotlin и хранить её в репозитории. Изменения конвейера проходят ревью как обычный код, откатываются через историю, а новые проекты поднимаются из готового описания. Типизация и автодополнение в IDE ловят ошибки до того, как упадёт сборка.
Что такое build chain?
Цепочка связанных сборок: компиляция, тесты и деплой — отдельные конфигурации, соединённые снапшот-зависимостями. Вся цепочка работает на одном наборе ревизий исходников, готовые результаты переиспользуются, независимые звенья идут параллельно, а при сбое перезапускается только упавшее звено.
Кому нужен навык TeamCity?
В первую очередь DevOps-инженерам — они проектируют и сопровождают конвейеры. Тестировщикам — они ежедневно запускают прогоны и разбирают упавшие тесты. Java- и Kotlin-разработчикам — TeamCity особенно распространён в их экосистеме. Отдельной профессии «инженер по TeamCity» нет: это инструмент внутри роли.
Сложно ли освоить TeamCity?
Старт лёгкий: сервер и агент поднимаются из Docker-образов, первая сборка настраивается за вечер через понятный интерфейс. Сложность растёт с глубиной — Kotlin DSL, цепочки, эксплуатация на десятках проектов. Главное условие — понимать сам процесс CI/CD: без него любой сервер останется набором кнопок.