Кейс TeamCity: автоматизация CI/CD пайплайна с объяснением принципов работы

Представьте себе среду, где каждая новая строка кода, отправленная разработчиком, автоматически проверяется, собирается, тестируется и готовится к развертыванию. Это не утопия, а реальность, которую обеспечивают системы непрерывной интеграции и доставки (CI/CD). TeamCity от JetBrains — одна из таких мощных и гибких платформ. В этом кейсе мы разберем реальный сценарий настройки пайплайна для веб-приложения, объясняя ключевые концепции и принципы работы системы.

Наш проект — это типичное веб-приложение на Node.js с фронтендом на React, хранящее код в GitLab. Задача: автоматизировать процесс от коммита до staging-окружения. Первым делом мы подключаем TeamCity к репозиторию GitLab через VCS Root. Здесь важно понять концепцию «триггеров». Мы настраиваем триггер «VCS trigger», который запускает сборку (build) при каждом пуше в ветку `main` или в любую feature-ветку. TeamCity постоянно опрашивает репозиторий (или использует webhooks) на наличие изменений.

Следующий этап — определение шагов сборки (Build Steps). Пайплайн в TeamCity — это последовательность шагов. Мы создаем несколько шагов, выполняемых на агенте (специальной машине, где происходят все операции). Первый шаг — «Command Line». Он выполняет `npm ci` (clean install) для установки зависимостей. Важно использовать `ci`, а не `install`, так как этот команда гарантирует воспроизводимость, используя точную версию зависимостей из `package-lock.json`. Принцип здесь — детерминированность: сборка должна давать одинаковый результат при одинаковых исходниках.

Второй шаг — запуск линтера (ESLint) и статического анализатора кода (SonarQube Scanner). Это этап контроля качества (Quality Gate). TeamCity не только выполняет команду, но и умеет парсить вывод, представляя предупреждения и ошибки в удобном интерфейсе. Если линтер или SonarQube обнаруживают критические проблемы, мы можем настроить условие завершения шага (Failure Conditions), чтобы вся сборка помечалась как неудачная. Это реализация принципа «раннего обнаружения ошибок».

Третий шаг — запуск unit-тестов с помощью Jest. TeamCity имеет встроенную поддержку многих фреймворков тестирования и может отображать статистику по тестам, время выполнения и историю успешных/проваленных тестов. Мы настраиваем шаг так, чтобы отчет о покрытии кода (code coverage) генерировался и публиковался как артефакт сборки. Артефакты — это файлы, производимые сборкой (JAR, отчеты, логи), которые TeamCity сохраняет и делает доступными для скачивания.

Четвертый шаг — сборка проекта. Для бэкенда это может быть простая упаковка файлов, для фронтенда — запуск `npm run build`, который создает оптимизированные статические файлы в папке `dist`. Результат этого шага (папка `dist`) также публикуется как артефакт.

Теперь ключевой момент — разветвление логики. Мы хотим, чтобы сборка для feature-веток останавливалась на этом этапе, а для ветки `main` — продолжалась до развертывания. Для этого мы используем концепцию «зависимостей сборок» (Build Chains) и «snapshot dependencies». Мы создаем две конфигурации: «Build and Test» (выполняет шаги 1-4) и «Deploy to Staging». Конфигурация деплоя зависит от успешной сборки «Build and Test». В триггере для `main` мы настраиваем запуск не только первой конфигурации, но и, по ее успеху, автоматический запуск второй.

Шаг деплоя использует либо SSH-выполнение команд на удаленном сервере, либо вызов скриптов Ansible/Terraform, либо взаимодействие с облачным провайдером (AWS CodeDeploy). В нашем кейсе мы используем шаг «SSH Upload», который копирует артефакт (папку `dist`) на staging-сервер по SSH, а затем выполняет команду на перезапуск службы Nginx.

Важнейшая фишка TeamCity — параметры (Parameters). Мы используем системные параметры (например, `%build.number%` — уникальный номер сборки) и определяем свои, например, `env.URL_STAGING`. Это позволяет делать конфигурации гибкими и переиспользуемыми. Также мы настраиваем «Build Features» — например, уведомления в Slack о начале, успехе или провале сборки.

В итоге наш пайплайн выглядит как отлаженный конвейер. Разработчик создает merge request. TeamCity автоматически запускает сборку для его ветки, проверяет код. Если все тесты проходят, разработчик мержит код в `main`. Это событие запускает полный цикл: сборка, тесты, анализ, деплой на staging. Инженерам по качеству (QA) не нужно никого просить об обновлении среды — она всегда содержит последнюю стабильную версию.

Этот кейс демонстрирует, как TeamCity абстрагирует сложность процессов CI/CD, предоставляя визуальный конструктор и мощные абстракции (агенты, шаги, триггеры, зависимости, артефакты). Принцип работы строится на событийной модели (VCS changes) и оркестровке задач на пуле агентов, что приводит к значительному ускорению разработки, повышению качества кода и снижению операционных рисков.