TeamCity Training Curriculum: CI/CD Course Outline, Labs, and Delivery Formats

Originally published on 2014-09-12; fully revised and updated.

This page turns the original training advertisement into a practical reference for SCM engineers, build and release engineers, and developers who want to adopt or improve Continuous Integration with TeamCity. You will find course goals, audience fit, delivery options, a hands-on pipeline workflow, and example lab commands.

Registration link from the original listing: TeamCity training registration form.

What this TeamCity course is designed to achieve

Based on the original post, the program is aimed at building practical CI/CD capability rather than only theory.

• Introduce core Continuous Integration concepts, benefits, and delivery pipeline thinking.
• Set up TeamCity projects, VCS roots, build steps, triggers, and build chains.
• Run language-specific builds across Java, .NET, Ruby, mobile, and plugin-based workflows.
• Integrate TeamCity with source control, IDEs, notifications, and external tooling.
• Prepare teams for production operations: backups, upgrades, external database setup, and diagnostics.

Audience and prerequisites

The original audience definition is broad but hands-on, with an emphasis on real project delivery.

• Primary audience: SCM engineers, build/release engineers, and developers.
• Expected background: working knowledge of software development in any language.
• Baseline understanding: Software Development Life Cycle fundamentals.
• Training style: practical labs (original post states approximately 80% lab work).

Delivery model and workshop structure

The source content mentions intensive 1-day and 2-day workshop formats and also describes the course as modular and customizable for team needs.

Curriculum roadmap at a glance

The original outline spans 12 sections, from CI fundamentals to production-ready TeamCity operations.

Phase 1: Foundations and setup

• Continuous Integration principles, practices, and pipeline basics.
• TeamCity fundamentals: licensing, agents, build chains, plugins, and dashboard usage.
• Installation and initial setup on Windows, macOS, and Linux.
• First pipeline: VCS roots, build configurations, triggers, failure conditions, and artifact/report basics.

Phase 2: Language and platform pipelines

• Java builds with Ant, Maven, and Gradle.
• .NET builds with NAnt, MSBuild, NUnit, NuGet, and PowerShell workflows.
• Ruby/Rails pipeline setup with Bundler and Rake.
• Mobile and plugin workflows for Android, iOS, Python, and Node-related tooling.

Phase 3: Integrations, scale, and delivery

• IDE and GitHub integrations, notifications, and project monitoring.
• Operational productivity: investigations, templates, meta-runners, cleanup, and priorities.
• Continuous Delivery patterns: artifact promotion, environment gates, and deployment permissions.
• Production readiness: external database use, backup/restore, upgrades, and diagnostics.

Hands-on workflow used in labs

The flow below reflects the build-chain and deployment-gate progression described in the course outline.

flowchart TD
    A[Developer pushes commit] --> B[TeamCity VCS trigger starts build]
    B --> C[Compile and run unit tests]
    C --> D{Build successful}
    D -- No --> E[Assign investigation and fix]
    D -- Yes --> F[Publish artifacts]
    F --> G[Deploy to test environment]
    G --> H[Run integration tests]
    H --> I{Release gate approved}
    I -- No --> E
    I -- Yes --> J[Promote build to next environment]

CI server comparison in course context

The source outline explicitly lists TeamCity and two competitors for comparison: Jenkins and ThoughtWorks Go (GoCD).

Example lab commands

These examples reflect the type of command-line work implied by the syllabus (installation, build execution, and CI feedback).

# Example: start and stop TeamCity on Linux
cd /opt/TeamCity/bin
./runAll.sh start
./runAll.sh stopCode language: PHP (php)

# Example: language-specific build commands often used in CI
mvn -B clean test
gradle clean build
dotnet restore
dotnet testCode language: PHP (php)

# Example: TeamCity service messages from build scripts
echo "##teamcity[setParameter name='env.DEPLOY_ENV' value='staging']"
echo "##teamcity[buildNumber '1.0.%build.counter%']"Code language: CSS (css)

Original contact and location details

From the original listing: contact info@scmGalaxy.com, phone +91 700 483 5930, Skype scmGalaxy. Cities mentioned include Bangalore, Delhi, Pune, Mumbai, and Hyderabad. For enrollment, use the linked registration form above.

Common pitfalls when planning TeamCity training

• Choosing a course before confirming whether you need team-level onboarding or individual upskilling.
• Skipping prerequisite checks for participants with limited SDLC or scripting exposure.
• Over-focusing on build success while under-investing in artifact promotion and environment gates.
• Not validating how CI server choice aligns with your long-term operations and support model.
• Using an old syllabus without checking current TeamCity and ecosystem changes.

Rajesh Kumar

I’m Rajesh Kumar, a DevOps, SRE, DevSecOps, Cloud, and Platform Engineering expert passionate about sharing practical knowledge, real-world experiences, and industry best practices. I have worked at Cotocus and regularly write about technology, travel, investing, health, product reviews, and digital marketing through my various platforms.

I publish technical articles at DevOps School, travel stories at Holiday Landmark, stock market insights at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow, and SEO and digital marketing strategies at Wizbrand.