Налаштування 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 | Jenkins |
|---|---|---|
| Конфігурація | Kotlin DSL (статична типізація) | Groovy (динамічна) |
| Паралельні збірки | Вбудований планувальник, швидше в 2 рази | Потребує налаштування |
| Шаблони середовищ | Нативні параметри та шаблони | Через бібліотеки |
| Артефакти | Вбудоване сховище | Плагін |
Замовте налаштування TeamCity — отримайте готовий пайплайн з документацією за 5-7 днів. Економія від $5000 на місяць на операціях деплою.
Розгортання деплою на кілька середовищ
Використовуємо шаблони з параметрами: env.name, env.url, ssh.host. Кожне середовище — окремий build type з прив'язкою до шаблону. VCS triggers на main запускають автоматичний деплой на staging; production — тільки вручну через UI. Це виключає випадковий деплой на прод.
Типові помилки при налаштуванні CI/CD
- Ігнорування artifactRules — артефакти не потрапляють в наступний білд, деплой ламається
- Відсутність ізоляції агентів — бібліотеки конфліктують, тести падають непередбачувано
- Хардкод credentials — ключі в коді, витік безпеки. Використовуємо параметри TeamCity та сховище паролів
- Занадто довгі пайплайни — всі кроки в одному білді, немає паралелізації. Ділимо на Build → Test → Deploy
- Немає сповіщень — команда дізнається про падіння збірки через кілька годин
Які проекти потребують автоматизації CI/CD?
Будь-який проект, де релізи частіше ніж раз на місяць, а деплой роблять вручну. Особливо якщо в команді більше двох розробників. TeamCity окупається за рахунок скорочення часу на збірку та виключення людських помилок. Наші клієнти — від фінтех-стартапів до enterprise-порталів — економлять від 10 до 40 годин на місяць на операціях деплою.
Що входить в роботу
- Аудит поточного процесу збірки та деплою (1 день)
- Встановлення сервера та агентів TeamCity (Docker або bare metal) — 1 день
- Налаштування VCS triggers, збірки, тестів та артефактів
- Шаблони для середовищ (dev/staging/production)
- Сповіщення про статус збірок (Slack, email)
- Тестування пайплайну та виправлення помилок
- Документація та навчання вашої команди
- Гарантія працездатності протягом місяця після здачі
Терміни та вартість
Вартість розраховується індивідуально після аналізу проекту. Орієнтовні терміни:
| Компонент | Час |
|---|---|
| Встановлення та базова конфігурація | 1 день |
| Kotlin DSL та шаблони | 1–2 дні |
| Інтеграція з VCS та тестами | 1 день |
| Деплой на середовища | 1–2 дні |
| Сповіщення та документація | 1 день |
Отримайте консультацію з налаштування TeamCity під ваш проект. Зв'яжіться з нами — ми допоможемо автоматизувати деплой без головного болю. Також ви можете запросити чек-лист з налаштування CI/CD.