Fix Your CI Without Leaving the IDE: TeamCity MCP and CLI | Artem Rokhin | GameDev Day 2026
In a Nutshell
TeamCity CLI and MCP let you debug CI failures—like missing Unity WebGL backgrounds—directly in Rider without switching tools. Both tools expose build logs, parameters, and pipeline status so you can spot the wrong "game build flavor" setting, fix the YAML, and watch the corrected pipeline run to completion. Game-dev extras such as Unity licensing, build caching, and test muting are fully supported in the same workflow.
These notes were generated by AI and may contain inaccuracies.
Artem Rokhin is a solutions engineer at JetBrains on the TeamCity team. He has been with JetBrains for approximately 12 years, previously working as a release manager helping teams get products to market faster. In the last year, he joined the TeamCity team to help clients build delivery pipelines on the TeamCity platform.
The presentation covers a quick introduction to TeamCity for those unfamiliar with the tool, followed by running a Unity project build process locally and testing it on the CI system. The build process will intentionally fail to demonstrate investigation of the failure. The core concept is conducting this investigation without leaving the context of Rider IDE using TeamCity CLI and MCP features.
TeamCity is JetBrains' continuous integration and deployment platform. The cloud version shows pipelines as connected tasks implemented sequentially, ending with a publishing step deploying to staging environment. The pipeline includes code reviews, security analyses, and tests. Tests compile, then the application builds for different platforms before deployment to testing environments.
TeamCity supports all game engines including Unity and Unreal with integrations for game development tools. For unit tests, there is a dedicated test tab showing all unit tests individually with execution times. Tests can be filtered by duration, and detailed test records show all processes involved in test implementation. Historical statistics track performance over time, showing all committed changes.
Test management features include the ability to check if tests experience random failures, assign investigations to team members, and mute tests. When muted, tests continue running but TeamCity ignores their results, useful for quickly unblocking release processes.
The Unity build step allows specification of necessary parameters including whether to run tests and operating modes such as enabling or disabling graphics. Unity license integration is managed through the TeamCity proxy concept. TeamCity agents are executors where code execution occurs. Cloud agents come in different sizes with various virtual systems. Unity license activation occurs once from TeamCity's side and applies to each agent automatically.
TeamCity enables parallel task execution to save time. Build cache functionality allows tasks at the beginning of the pipeline to obtain elements that subsequent steps can reuse. Automatic activation triggers with every new repository change, monitoring all modifications. Scheduled triggers are useful for heavy-duty tasks like performance tests or large deployments that should run overnight.
New tasks can be added through a dedicated interface by specifying a name and adding steps such as Unity builds or tests. Tasks can be assigned to run in parallel with other scans. TeamCity settings are stored as source code within the repository as YAML files alongside game code.
The game developer has completed Unity game changes and is ready to share results with quality engineers and end users. Before sharing, the developer builds the game locally. The local build works on localhost with full functionality including vehicle selection, control, turning, and firing weapons on a moon surface environment.
After committing changes, TeamCity detected modifications and ran the full pipeline successfully. The WebGL build and deployment configuration publishes to AWS via CloudFront. However, the deployed game shows a missing background compared to the local version, while vehicle control and shooting functionality remain intact.
The scenario demonstrates a common situation where functionality works locally but fails in remote/CI environments. Investigation typically involves checking parameters, functions, code, and settings across multiple contexts including Unity settings, Rider IDE, and TeamCity, requiring repeated context switching.
The TeamCity command-line interface enables interaction with TeamCity servers directly from the console. After logging in to demo.teamcity.com, users can check recent operations using commands like "TeamCity run list" with project IDs. The "TeamCity view" command displays tasks within execution lines, and log viewing provides detailed execution information including corrections, warnings, and errors.
Log search functionality allows filtering for specific terms like "flavor" to identify relevant parameters. The "game build flavor" parameter was set to "diagnostics," explaining the missing background. TeamCity stores all settings as code in YAML files within the repository, allowing identification of the "diagnostic" environment setting that needed changing to "game."
After changing the flavor parameter from "diagnostic" to "game" and committing the change with message "Updated flavor parameters," TeamCity automatically detected the modification and triggered the workflow. The pipeline execution began with code review, code analysis, and test phases.
TeamCity provides an MCP endpoint configurable within Rider settings under Tools > Assistance > MCP. Authorization codes can be created with defined scopes ranging from general to project-specific, including read-only permissions for specific projects to limit AI agent capabilities. The AI chat interface allows direct interaction with TeamCity through MCP connections.
Using the AI agent ("cloud" proxy), queries can be made to investigate background issues in test environments versus local machines. The MCP connection detected 45 operations and identified the "flavor of bits" set to diagnostics as the primary cause. The AI provided additional details including the committed fix and pipeline monitoring capabilities.
The pipeline reached 50% completion with WebGL processing underway. Upon completion, the test environment URL showed successful deployment with the moon background visible, matching local machine behavior. Vehicle control and map exploration functionality worked correctly.
Two methods exist for investigating CI problems directly from Rider without context switching: TeamCity CLI and TeamCity MCP. Both approaches enable staying within a single interface to solve problems related to continuous integration, infrastructure, or other issues.
TeamCity pipelines use a YAML-based approach for quick and easy pipeline configuration similar to GitHub Actions. Game development-specific features include seamless support for all game engines, optimization features like build caching, unit test management with mute and investigation capabilities, and support for complex multi-platform deployment pipelines.
A survey during the session showed the command-line interface ranked highest among methods for interacting with CI systems. The CLI approach also works effectively with MCP and AI integration.
TeamCity includes an AI assistant for settings help, dependency configuration, build features, and other configuration tasks. An AI-based build analyst examines build failures using TeamCity's build and repository settings context to provide explanations and recommendations. Additional AI features are under development.
Build artifacts can be hosted within TeamCity or configured with external storage like S3. Pricing calculators on the website provide exact costs based on manufactured data size. TeamCity offers three deployment modes: on-premises (local infrastructure management), cloud SaaS (hosted agents including Windows, Linux, Mac), and hybrid mode (cloud-managed server with agents running in user infrastructure).
Hybrid mode allows game studios to keep code locally while having TeamCity server management handled by JetBrains as SaaS. Kubernetes integration enables automatic scaling where pods run only when needed, shutting down when idle with no charges for inactive resources.
The new pipeline system improves understanding of processes and setup ease. Contact information for demonstrations or discussions is available at jetbrains.com/teamcity.
Keep JetBrains in your library
Save the videos and channels worth coming back to, and find them again in one place.
