TeamCity Trainer

The practice before the product. What continuous integration actually requires of a team, how continuous delivery and continuous deployment differ, and what a build pipeline is meant to guarantee. Then TeamCity itself: architecture, licensing model, the feature set that distinguishes it, and a direct comparison with Jenkins and other CI servers including where TeamCity is the wrong choice.

Topics: CI practices and the benefits that justify them · Continuous delivery versus continuous deployment · The build pipeline as a quality gate · Introduction to TeamCity and its architecture · Licensing and agent economics · First-class support for many technologies, plugins and the REST API · Comprehensive VCS support, dashboard and build history · Build chains, agents and build grids · IDE integrations · TeamCity compared with Jenkins and other CI servers

• Assignments: (1) Map an existing manual build and release process to a pipeline diagram with gates; (2) Write a short comparison arguing for or against TeamCity for a specific estate
• Capstone: Produce a CI adoption plan for one real product, naming the gates and what each one blocks

Getting a real server and grid running. Installation on Windows, Linux and macOS, running server and default agent, adding further agents, and running both as services or daemons so they survive a reboot. Then the topology decisions that matter later: where the data directory lives, how agents are authorised, and how agents are containerised or provisioned on demand.

Topics: Installing TeamCity on Windows, including server and default agent · Installation on Linux and macOS · Running the server and agent as a service or daemon · Installing and authorising additional agents · The TeamCity data directory and what must be backed up · Agent pools and capacity planning · Dockerised agents and cloud agent profiles · Agent requirements and compatibility

• Assignments: (1) Stand up a server with two agents on different operating systems and prove both pick up work; (2) Create an agent pool and route a build to it using an explicit requirement
• Capstone: Design an agent topology for a mixed Windows and Linux build estate with stated capacity assumptions

The first working pipeline. Creating a project and subprojects, adding build configurations, attaching VCS roots and configuring checkout rules and branch specifications, then defining build steps and running the first build. Ending with the two things that make a build meaningful: failure conditions and triggering on VCS change.

Topics: Creating a project and using subprojects · Adding build configurations · VCS roots, VCS settings and checkout rules · Branch specifications and feature branch builds · Introducing build steps and runners · Running the first build and reading the build log · Build failure conditions, including metric-based failures · Triggering builds on VCS changes and on schedule

• Assignments: (1) Create a project with two build configurations sharing one VCS root; (2) Make a build fail on a metric rather than an exit code, and prove it
• Capstone: Deliver a compile-and-test pipeline for a real repository, triggered automatically on every commit

Where TeamCity stops resembling a job runner. Snapshot dependencies that pin a whole chain to one set of revisions, artifact dependencies that pass outputs downstream, the finish build trigger, and the build chain view as a diagnostic tool. Then parameters — system, environment and configuration — plus shared resources and agent requirements that keep parallel builds from colliding.

Topics: Snapshot dependencies and consistent revisions across a chain · Artifact dependencies and passing outputs downstream · The finish build trigger · Reading and debugging the build chain view · Parameters: system properties, environment variables and configuration parameters · Typed parameter specs and prompts · Shared resources and locks · Agent requirements and build priorities · Adding functional tests as a downstream stage

• Assignments: (1) Build a three-stage chain — compile, test, package — with correct snapshot and artifact dependencies; (2) Use a shared resource to serialise two builds that contend for one database
• Capstone: Refactor a monolithic build configuration into a chain whose failure point is obvious from the chain view

Making build results answer questions. Publishing artifacts and controlling what is kept, XML report processing so external tool output becomes first-class test data, code coverage reporting, custom report tabs, and the build and project statistics that reveal trends — including flaky tests and creeping build duration.

Topics: Publishing artifacts and artifact paths · Artifact rules, dependencies and access patterns · XML report processing for external test tools · Adding coverage and unit test reports · Custom report tabs · Build and project statistics and custom charts · Test history, muting and flaky test detection · Investigations and assigning failures

• Assignments: (1) Feed an external test tool's XML output into TeamCity so failures appear as tests, not log text; (2) Add a coverage report and a custom statistic chart to an existing configuration
• Capstone: Instrument a pipeline so a reviewer can judge build health without opening a single build log

TeamCity against a real JVM toolchain. Ant, Maven and Gradle runners; building from POM and Gradle scripts; setting version numbers from build counters; wiring code coverage; and the distinction that decides long-term maintainability — what belongs in the build script versus what belongs in a TeamCity feature.

Topics: Using Ant with TeamCity: build files and unit tests · Maven: POM basics, the Maven runner and build configuration · Setting the version number from TeamCity · Code coverage for JVM builds · Global Maven settings and server-side settings · Maven-based triggers and snapshot dependency triggers · Using Gradle with TeamCity · Build scripts versus TeamCity features · System properties and how they reach the build

• Assignments: (1) Build the same project with Maven and with Gradle and compare what TeamCity reports for each; (2) Move version stamping out of the build script and into TeamCity, or argue why it should stay
• Capstone: Deliver a JVM pipeline producing a versioned, tested, published artifact on every commit to main

The stack TeamCity is often chosen for. NAnt and MSBuild runners, NUnit tests run both as a task and via the TeamCity runner, code coverage under MSBuild, and agent requirements for toolchain versions. Then NuGet end to end — the command-line client on agents, TeamCity acting as a NuGet server, the NuGet runners and the dependency trigger — plus PowerShell as a build and deployment language.

Topics: Getting started with NAnt on TeamCity · Building with MSBuild and the .NET runner · NUnit report processing, and running tests via task versus runner · Configuring code coverage with MSBuild · Configuring agent requirements for toolchain versions · Installing the NuGet client on agents · TeamCity as a NuGet server · NuGet build runners and the NuGet dependency trigger · PowerShell build tools and the PowerShell runner · Database migrations in a .NET pipeline

• Assignments: (1) Build, test and package a .NET solution with coverage and NUnit results surfaced in TeamCity; (2) Publish a package to TeamCity's NuGet feed and consume it from a second build configuration
• Capstone: Deliver a .NET pipeline including package publication and a dependency-triggered downstream build

TeamCity beyond the JVM and .NET. Ruby and Rails builds with version managers, Bundler and Rake; Node and Python via plugins and runners; and mobile pipelines — generating an Android APK and running instrumentation or Calabash tests, plus the agent constraints that iOS builds impose.

Topics: Ruby version management and setting the interpreter · Bundler, Rake and a Rails build on TeamCity · Running Capybara and Selenium feature tests · CI for Android projects and generating the APK · Building iOS projects and macOS agent requirements · Installing and managing TeamCity plugins · The Python build runner · Node builds and the TeamCity.Node plugin · Docker-based build steps for language isolation

• Assignments: (1) Build a non-JVM project end to end and surface its test results natively in TeamCity; (2) Constrain a mobile build to the only agents capable of running it, and prove the routing
• Capstone: Add a second technology stack to an existing TeamCity estate without duplicating pipeline logic

How an estate stays maintainable past fifty build configurations. Templates created from scratch and extracted from existing configurations, meta-runners that package a sequence of steps as a reusable runner, and versioned settings that put an entire project's configuration into its own repository as Kotlin DSL — reviewed, branched and diffed like application code.

Topics: Build configuration templates from scratch · Creating build configurations from a template · Extracting a template from an existing configuration · Meta-runners and when to build one · Versioned settings: Kotlin DSL and XML · Migrating an existing project to versioned settings without a rewrite · Testing and reviewing DSL changes · Interacting with TeamCity from build scripts: service messages · teamcity-info.xml and reporting from inside a build

• Assignments: (1) Extract a template from three near-identical configurations and prove drift is gone; (2) Convert one project to Kotlin DSL versioned settings and change it through a pull request
• Capstone: Deliver a project whose entire pipeline definition lives in version control and is reviewed like code

Taking the chain past build. What continuous delivery requires structurally, implementing a deployment pipeline in TeamCity, publishing and consuming artifacts so the exact tested binary is what deploys, environments as gates, identifying which build is currently deployed where, and redeploying any historical version. Then the controls: who may deploy, and how sensitive values are passed without leaking.

Topics: What continuous delivery is and why it changes pipeline shape · Implementing the deployment pipeline in TeamCity · Publishing and consuming artifacts across the chain · Deploying to environments and environments as gates · Identifying the build deployed in an environment · Deploying any version to an environment · Build result actions: comment, tag, pin and promote · Limiting deployment permissions to specific users · Passing sensitive information during deployment · Feature branching and feature toggling in a CI context

• Assignments: (1) Promote one build artifact through dev, staging and production configurations with a manual gate; (2) Restrict production deployment to a single role and prove another user cannot trigger it
• Capstone: Deliver a deployment pipeline that can redeploy any previous release on demand, with permissions enforced

Operating the server as production infrastructure. Moving off the internal database to PostgreSQL and migrating between databases, backups taken from the UI and with maintainDB plus manual backups of the data directory, upgrading server and agents in the right order, and the diagnostics that matter when builds slow down: disk usage, thread dumps, memory and JVM tuning.

Topics: Using TeamCity with an external database · Configuring PostgreSQL as the external database · Migrating from one database to another · Backups from the server UI and with the maintainDB tool · Manual backup of the data directory, and restore testing · Upgrading a server installed from an archive or installer · Upgrading agents and version compatibility · Disk space, build history cleanup rules and archiving projects · Server diagnostics, thread dumps and performance monitoring · Tweaking the TeamCity JVM

• Assignments: (1) Migrate a running server to PostgreSQL and verify no history is lost; (2) Restore a backup into a clean server and confirm builds, artifacts and history came with it
• Capstone: Produce an operations runbook: backup schedule, restore procedure, upgrade order and cleanup policy

Running TeamCity for an organisation. User accounts, groups, roles and the permission model that decides who can edit a configuration or deploy to production; notification rules that people actually read; licence management; assigning build configurations to specific agents; integrating with issue trackers, code quality and artifact repositories; and tracking user actions when someone asks what changed.

Topics: Managing user accounts, groups, roles and permissions · Authentication options and directory integration · Customising notifications and notification rules · Managing licences and agent licences · Managing projects and build configurations at scale · Assigning build configurations to specific build agents · Integrating with issue trackers, SonarQube and artifact repositories · Patterns for accessing build artifacts, including from outside TeamCity · REST API and automating server administration · Tracking user actions and the audit trail

• Assignments: (1) Design a role and permission scheme separating build editors from deployers, and implement it; (2) Automate a routine administration task through the REST API
• Capstone: Deliver a governed TeamCity estate: permissions, notifications, integrations and an audit story