Deploying with TeamCity
JetBrains CI/CD server with .NET and Java support, DSL-based pipeline configuration.
CI/CDIntermediate
Why
TeamCity provides excellent .NET/Java tooling, VCS-backed DSL, and reliable build chains with artifact dependencies. DORA's 2024 State of DevOps report shows elite teams deploy 973x more frequently than low performers.
CI/CD pipelines with automated testing reduce change failure rate to 5-15% versus 40-60% for manual deployments.
When
Java or .NET projects needing IDE-integrated CI with rich build features.
How
# TeamCity Kotlin DSL
version = "2024.1"
project {
buildType {
id = "Build"
name = "Build and Test"
steps {
gradle { tasks = "clean build" }
}
artifactRules = "+:build/libs/*.jar"
}
buildType {
id = "Deploy"
name = "Deploy to Prod"
dependsOn(AbsoluteId("Build"))
steps {
script {
scriptContent = "kubectl apply -f k8s/"
}
}
}
}
4. Verify deployment — curl -I https://your-app.example.com
5. Monitor logs — check for errors in first 5 minutes
6. Rollback if needed — revert to previous version
Example
// config — deploy-teamcity
const config = require("./config");
# Docker-based TeamCity agent
FROM jetbrains/teamcity-agent:latest
ENV SERVER_URL=http://teamcity:8111
COPY gradle.properties /opt/buildagent/conf/
Common Problems
- ⚠Agent out of disk — clean build artifacts regularly
- ⚠DSL not syncing — use TeamCity DSL watcher
- ⚠Configuration drift between environments — use infrastructure-as-code (Terraform/Pulumi) to keep dev/staging/prod identical
Best Practices
- ✓Use Kotlin DSL — version-controlled pipeline config
- ✓Use build chains with artifact dependencies — avoid rebuilds
- ✓Set up health checks and graceful shutdown — handle SIGTERM to drain in-flight requests before exit