2nd/10_Wiki/Topics/Domain_Programming/Programming & Language/TeamCity.md

id, title, category, status, canonical_id, aliases, duplicate_of, source_trust_level, confidence_score, verification_status, tags, raw_sources, last_reinforced, github_commit, tech_stack

id	title	category	status	canonical_id	aliases	duplicate_of	source_trust_level	confidence_score	verification_status	tags	raw_sources	last_reinforced	github_commit	tech_stack
wiki-2026-0508-teamcity	TeamCity	10_Wiki/Topics	verified	self	JetBrains TeamCity TC	none	A	0.9	applied	ci-cd jetbrains build devops		2026-05-10	pending	language framework Kotlin DSL TeamCity 2025.x

TeamCity

매 한 줄

"매 enterprise CI server with first-class build chains + Kotlin DSL config". JetBrains TeamCity 는 build configuration 의 strong dependency graph + snapshot/artifact dep + 매 versioned settings (Kotlin DSL) 를 제공하는 self-hosted CI. 2026 의 TeamCity 2025.x 는 cloud agents + GitHub Actions 호환성 + native AI test analytics.

매 핵심

매 핵심 개념

• Project / Build Configuration / Build: 3-tier hierarchy.
• Snapshot dependency: 매 동일 VCS revision 보장된 build chain.
• Artifact dependency: 매 upstream artifact pull.
• Build chain: composite build (status rollup).
• Versioned settings: 매 Kotlin DSL .teamcity/settings.kts git 관리.

매 vs Jenkins / GitHub Actions

• 매 Jenkins: plugin sprawl, 매 declarative 선택적.
• 매 GitHub Actions: SaaS-first, 매 enterprise 의 self-host 약함.
• 매 TeamCity: 매 enterprise self-host + Kotlin DSL + 매 strong test history.

매 응용

1. JVM monorepo (Gradle/Maven) build chain.
2. .NET / Kotlin Multiplatform CI.
3. Hybrid cloud agents (AWS/GCP/K8s) + on-prem.

💻 패턴

Kotlin DSL 의 build config

import jetbrains.buildServer.configs.kotlin.*
import jetbrains.buildServer.configs.kotlin.buildSteps.gradle

object Build : BuildType({
    name = "Build & Test"
    vcs { root(DslContext.settingsRoot) }
    steps {
        gradle {
            tasks = "clean build"
            useGradleWrapper = true
        }
    }
    triggers { vcs {} }
    features {
        perfmon {}
    }
})

Build chain (snapshot dep)

object Deploy : BuildType({
    name = "Deploy"
    dependencies {
        snapshot(Build) { onDependencyFailure = FailureAction.FAIL_TO_START }
        artifacts(Build) { artifactRules = "build/libs/*.jar => libs" }
    }
})

Parameter + secret

params {
    param("env.NODE_ENV", "production")
    password("env.NPM_TOKEN", "credentialsJSON:...")
}

Agent requirements

requirements {
    contains("teamcity.agent.jvm.os.name", "Linux")
    exists("env.DOCKER_HOST")
}

Matrix-style (composite build)

object Matrix : BuildType({ name = "All Platforms"; type = Type.COMPOSITE
    dependencies {
        snapshot(BuildLinux) {}
        snapshot(BuildMac)   {}
        snapshot(BuildWin)   {}
    }
})

REST API trigger

curl -u user:token -X POST \
  -H "Content-Type: application/xml" \
  -d '<build><buildType id="Build"/></build>' \
  https://tc.example.com/app/rest/buildQueue

Cloud agent profile (Kubernetes)

features {
    feature {
        type = "CloudImage"
        param("cloud-code", "kubernetes")
        param("image-name", "myorg/tc-agent:2025")
    }
}

매 결정 기준

상황	CI choice
매 JVM enterprise self-host	TeamCity
매 GitHub-centric OSS	GitHub Actions
매 plugin-heavy legacy	Jenkins
매 GitLab-native	GitLab CI
매 monorepo with cache focus	Buildkite / Bazel CI

기본값: 매 enterprise JVM/.NET 의 TeamCity, 매 OSS GitHub repo 의 Actions.

🔗 Graph

• 부모: CI_CD_Pipeline
• 변형: GitHub_Actions

🤖 LLM 활용

언제: 매 enterprise CI 설계, 매 build chain 의존성 모델링, 매 Kotlin DSL 마이그레이션. 언제 X: 매 single-repo OSS — 매 GitHub Actions 가 zero-ops.

❌ 안티패턴

• UI-only config (no DSL): 매 settings drift, 매 review 불가능.
• Snapshot dep 없이 chain: 매 inconsistent revision.
• Agent 의 secret 평문 저장: 매 Token credentials 사용 필수.
• Build history retention 무한: 매 server 디스크 폭발.

🧪 검증 / 중복

• Verified (JetBrains TeamCity 2025 docs, Kotlin DSL guide).
• 신뢰도 A.

🕓 Changelog

날짜	변경
2026-05-08	Phase 1
2026-05-10	Manual cleanup — TeamCity 2025 + Kotlin DSL