Был ли у вас опыт работы с TeamCity?

«Был ли у вас опыт работы с TeamCity?» — вопрос из категории CI/CD, который задают на 23% собеседований Devops Инженер. Ниже — развёрнутый ответ с разбором ключевых моментов.

Ответ

Да, я использовал TeamCity в качестве CI/CD-сервера для сборки, тестирования и деплоя Java, .NET и Docker-приложений.

Ключевые задачи, которые я решал:

  1. Настройка проектов и цепочек сборок (Build Chains): Организовывал сложные пайплайны, где сборка, статический анализ (SonarQube), создание Docker-образов и деплой были разнесены по разным шагам с зависимостями.
  2. Интеграция с VCS: Настраивал триггеры на коммиты и пулл-реквесты в Git (GitHub, GitLab, Bitbucket). Использовал feature branches и pre-tested commits.
  3. Управление агентами: Настраивал пулы агентов с разным окружением (например, отдельные агенты для сборки под Windows, Linux и для запуска Docker).
  4. Работа с артефактами: Настраивал правила хранения и очистки артефактов (Docker-образы, jar/nuget-пакеты).
  5. Интеграция с инфраструктурой: Настраивал уведомления в Slack, деплой через SSH или Ansible, загрузку артефактов в Nexus/Artifactory.

Пример конфигурации шага сборки Maven-проекта через Kotlin DSL:

package _Self.buildTypes

import jetbrains.buildServer.configs.kotlin.v2019_2.*
import jetbrains.buildServer.configs.kotlin.v2019_2.buildSteps.maven

object Build : BuildType({
    name = "Build and Unit Test"

    vcs {
        root(DslContext.settingsRoot)
    }

    steps {
        maven {
            goals = "clean compile"
            runnerArgs = "-DskipTests"
        }
        maven {
            goals = "test"
            jdkArgs = "-Xmx2g"
        }
    }

    triggers {
        vcs {
            branchFilter = "+:*"
        }
    }
})

Для управления конфигурацией использовал подход "Configuration as Code" с хранением Kotlin DSL в Git, что позволяло легко отслеживать изменения и проводить code review для конфигураций CI/CD.