Налаштування CI/CD пайплайну на TeamCity: покроковий гід

Уявіть: інтернет-магазин на Node.js з трьома середовищами (dev, staging, production). Кожна збірка — з нуля, залежності тягнуться з npm без кешу, тести прогоняються послідовно. На деплой йшло 40 хвилин, а відкат — ручне перезаливання архіву по SSH. Після аудиту ми налаштували TeamCity: паралельні кроки, кешування node_modules, автоматичні тести в контейнерах. Час збірки впав до 8 хвилин — у 5 разів швидше. Розробники перестали чекати, а релізи стали виходити щодня. Така економія часу напряму знижує TCO і прискорює вихід фіч в прод. Наша команда з 10-річним досвідом і понад 50 успішних інтеграцій налаштує CI/CD під ключ: від встановлення сервера до документації.

Типові технічні складності

N+1 запит в тестах — TeamCity збирає звіти про покриття і знаходить вузькі місця на етапі CI. Брудні середовища — кожен білд на чистому Docker-агенті, конфлікти виключені. Довгі збірки — паралельні кроки та кешування залежностей (npm cache, Maven local) скорочують час до 70%. Для типового Node.js проекту збірка з кешем займає 2-3 хвилини замість 10. Середній час відновлення після збою скорочується до 15 хвилин завдяки автоматичним відкатам.

Налаштування пайплайну: Kotlin DSL та кроки

Використовуємо Kotlin DSL — конфігурація як код, версіонується в Git і проходить code review. TeamCity підтримує складні пайплайни з паралельними кроками. Нижче — типовий пайплайн для Node.js додатку:

// .teamcity/settings.kts import jetbrains.buildServer.configs.kotlin.* import jetbrains.buildServer.configs.kotlin.buildSteps.* import jetbrains.buildServer.configs.kotlin.triggers.* version = "latest" project { buildType(Build) buildType(Test) buildType(Deploy) buildTypesOrder = arrayListOf(Build, Test, Deploy) } object Build : BuildType({ name = "Build" vcs { root(DslContext.settingsRoot) } steps { nodeJS { shellScript = "npm ci && npm run build" } } artifactRules = "dist/** => dist.zip" }) object Test : BuildType({ name = "Test" dependencies { snapshot(Build) {} } steps { script { scriptContent = """ npm ci npm test -- --coverage --ci """.trimIndent() } } failureConditions { testFailure = true errorMessage = true } }) object Deploy : BuildType({ name = "Deploy to Production" type = Type.DEPLOYMENT dependencies { snapshot(Test) {} artifacts(Build) { artifactRules = "dist.zip => ." } } params { param("deploy.env", "production") } steps { script { scriptContent = """ unzip dist.zip -d /var/www/app/ sudo systemctl reload nginx """.trimIndent() } } triggers { vcs { branchFilter = "+:refs/heads/main" } } }) 

Деплой через SSH

Для PHP-проектів (Laravel, Symfony) додали SSH-крок:

sshExec { commands = """ cd /var/www/app git pull origin main composer install --no-dev --optimize-autoloader php artisan migrate --force php artisan config:cache php artisan route:cache php artisan view:cache sudo systemctl reload php8.3-fpm """.trimIndent() targetUrl = "deploy-server.example.com" authMethod = uploadedKey { username = "deploy" key = "deploy_key" } } 

Docker-збірка в TeamCity

Контейнеризація уніфікує середовище і позбавляє від помилок «на моїй машині працює».

steps { dockerCommand { commandType = build { source = file { path = "Dockerfile" } namesAndTags = "registry.example.com/myapp:%build.counter%" commandArgs = "--no-cache" } } dockerCommand { commandType = push { namesAndTags = "registry.example.com/myapp:%build.counter%" } } } 

Параметри та шаблони

Багатосередовищні проекти (staging, production) налаштовуємо через шаблони. Один шаблон — три середовища, мінімум коду.

template("DeployTemplate") { params { param("env.name", "") param("env.url", "") param("ssh.host", "") } steps { script { scriptContent = "deploy.sh %env.name% %env.url%" } } } object DeployStaging : BuildType({ templates(DeployTemplate) params { param("env.name", "staging") param("env.url", "https://staging.example.com") param("ssh.host", "staging.server.com") } }) 

Чому TeamCity виграє у Jenkins?

TeamCity швидший при паралельних збірках — у два рази, завдяки вбудованому артефакто-сховищу та розумному планувальнику. Kotlin DSL дає типізацію та автодоповнення в IDE, тоді як Jenkins Pipeline — Groovy з динамічною типізацією, що часто веде до помилок рантайму. Нативні шаблони та параметри середовищ TeamCity спрощують масштабування на десятки проектів. Для наочності:

Замовте налаштування TeamCity — отримайте готовий пайплайн з документацією за 5-7 днів. Економія від $5000 на місяць на операціях деплою.

Розгортання деплою на кілька середовищ

Використовуємо шаблони з параметрами: env.name, env.url, ssh.host. Кожне середовище — окремий build type з прив'язкою до шаблону. VCS triggers на main запускають автоматичний деплой на staging; production — тільки вручну через UI. Це виключає випадковий деплой на прод.

Які проекти потребують автоматизації CI/CD?

Будь-який проект, де релізи частіше ніж раз на місяць, а деплой роблять вручну. Особливо якщо в команді більше двох розробників. TeamCity окупається за рахунок скорочення часу на збірку та виключення людських помилок. Наші клієнти — від фінтех-стартапів до enterprise-порталів — економлять від 10 до 40 годин на місяць на операціях деплою.

Що входить в роботу

• Аудит поточного процесу збірки та деплою (1 день)
• Встановлення сервера та агентів TeamCity (Docker або bare metal) — 1 день
• Налаштування VCS triggers, збірки, тестів та артефактів
• Шаблони для середовищ (dev/staging/production)
• Сповіщення про статус збірок (Slack, email)
• Тестування пайплайну та виправлення помилок
• Документація та навчання вашої команди
• Гарантія працездатності протягом місяця після здачі

Терміни та вартість

Вартість розраховується індивідуально після аналізу проекту. Орієнтовні терміни:

Отримайте консультацію з налаштування TeamCity під ваш проект. Зв'яжіться з нами — ми допоможемо автоматизувати деплой без головного болю. Також ви можете запросити чек-лист з налаштування CI/CD.