Настройка CI/CD пайплайна на TeamCity: Kotlin DSL, шаблоны и деплой

Представьте: интернет-магазин на Node.js с тремя окружениями (dev, staging, production). Каждая сборка — с нуля, зависимости тянутся из npm без кэша, тесты прогоняются последовательно. На деплой уходило 40 минут, а откат — ручной перезалив архива по SSH. После аудита мы настроили TeamCity: параллельные шаги, кэширование node_modules, автоматические тесты в контейнерах. Время сборки упало до 8 минут — в 5 раз быстрее. Разработчики перестали ждать, а релизы стали выходить каждый день. Такая экономия времени напрямую снижает TCO и ускоряет выход фич в прод. Наша команда с 10-летним опытом настроит 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 дней.

Как развернуть деплой на несколько окружений?

Используем шаблоны с параметрами: 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.