Rider TeamCity
На GameDev Day 2026, инженер по решениям TeamCity Артем Рохин продемонстрировал, как исследовать проблему CI из Rider с помощью TeamCity CLI и интеграции с MCP.
Для демо он использовал игру на Unity, которая работала локально, но на стейджинге у нее отсутствовал фон. Хотя сборка прошла успешно, Артем использовал CLI для проверки логов и обнаружил неверный параметр сборки.
После фиксации исправления он попросил AI-агента, подключенного через MCP, объяснить проблему и проследить за новой сборкой.
Давайте разберем этот пример, а также команды и настройку, которые понадобятся вам для его проверки на собственном проекте.
Проблема на стейджинге
В демо Артема игра на Unity работает локально, но на стейджинге у нее отсутствует лунный пейзаж, несмотря на успешную сборку TeamCity. Он отслеживает развертывание до соответствующей сборки и проверяет логи и конфигурацию, чтобы найти отличия от локальной настройки.
Что вам нужно
Чтобы применить этот рабочий процесс к вашему собственному проекту, вам потребуется:
- Проект Unity, открытый в Rider.
- Конвейер TeamCity, который собирает и развертывает проект, причем его настройки YAML хранятся в репозитории.
- Доступ к деталям сборки и логам этого конвейера.
- TeamCity CLI, установленный на вашем компьютере.
- Для работы с AI — активированный агент с поддержкой MCP в Rider и доступ к конечной точке MCP в TeamCity. Артем использует Claude Agent.
В записи используется TeamCity Cloud. Пользователи TeamCity On-Premises могут использовать версию 2026.2 в качестве базовой с общедоступными конвейерами (Pipelines). Подробнее о настройке и версиях см. в документации по Pipelines.
В командах ниже используются примеры ID. Замените MyGame_BuildWebGL на ID вашего задания WebGL, 12345 — на исследуемую сборку, а 12346 — на новый запуск развертывания, когда вы дойдете до этого шага.
Подключение TeamCity CLI из Rider
Откройте терминал Rider и установите TeamCity CLI, если вы еще этого не сделали. В macOS с помощью Homebrew:
В Windows с помощью WinGet:
Другие способы установки описаны в руководстве по началу работы.
Подключитесь к серверу и проверьте соединение:
Замените URL-адрес на адрес вашего собственного TeamCity. Процесс входа может открыть ваш браузер для авторизации. Доступные методы описаны в документации по аутентификации.
После подключения вернитесь в терминал Rider для проверки сборки.
Поиск сборки, создавшей игру
Выведите список недавних запуск задания WebGL:
Выберите запуск, который создал версию на стейджинге. Включите успешные запуск в поиск: в этом примере соответствующая сборка отмечена зеленым.
Если за последнее время было завершено несколько запусков, перед началом исследования проверьте исходную сборку и ревизию развертывания. Самая свежая сборка WebGL может оказаться новее версии, открытой у вас в браузере.
Проверьте выбранный запуск:
В записи Артем начинает с запуска конвейера, определяет его задание WebGL, а затем открывает детали сборки этого задания. Переход напрямую к недавним запускам задания WebGL — это более короткий путь, когда вы уже знаете, какое именно задание создало игру.
Проверка логов и конфигурации
Прочитайте лог сборки WebGL:
Средство просмотра логов по умолчанию поддерживает поиск. Нажмите /, введите термин и используйте клавиши n или N для перемещения между совпадениями. Подробные сведения о командах можно найти в руководстве по управлению запусками.
Артем недавно работал с вариантами сборки (build flavors), поэтому он ищет слово flavor. В логе видно, что при сборке использовался параметр gameBuildFlavor со значением diagnostic.
Это дает конкретную настройку для исследования. Выполните поиск gameBuildFlavor в проверенном проекте, включая как конфигурацию конвейера, так и код сборки Unity, который ее использует.
Значение, выведенное в логе, показывает, что именно получила CI-сборка; репозиторий помогает проследить, откуда оно взялось и чем управляет.
В этом демонстрационном проекте ожидаемое значение flavor — game. Значение diagnostic связано с версией, у которой отсутствует фон. Эти имена являются частью настроек сборки примера проекта; в вашем проекте может использоваться другой параметр или вообще отсутствовать переключатель вариантов.
При исследовании аналогичной проблемы проверяйте как определение, так и код, который использует это значение. Обнаружение неожиданного параметра — весомое доказательство. Понимание его влияния на сборку позволяет оценить, устраняет ли его изменение симптом.
Фиксация изменений конфигурации
Артем находит значение diagnostic в YAML-конфигурации конвейера и меняет его на game. Поскольку конфигурация хранится рядом с кодом игры, он может просмотреть и зафиксировать изменения прямо из Rider.
TeamCity настроен на отслеживание репозитория, поэтому отправка этого коммита запускает новый конвейер. В этой настройке вам не нужно перезапускать старую сборку вручную.
Для собственного конвейера проверьте настройки триггеров и убедитесь, что новый запуск включает в себя коммит конфигурации. Сохраните ID исходного запуска, чтобы впоследствии можно было сравнить настройки и результаты.
Пока выполняется новый конвейер, Артем демонстрирует другой способ исследования результатов CI из Rider: AI-агент, подключенный к TeamCity через MCP.
Подключение Rider к TeamCity MCP
MCP предоставляет агенту доступ к инструментам TeamCity, включая инструменты для получения логов и запроса информации о сборках. Конечная точка сервера:
Для этого исследования создайте токен доступа TeamCity, ограниченный соответствующим проектом, с пресетом «Только чтение» (Read-only). Этого достаточно для проверки результатов CI во время внесения изменений конфигурации через Git. См. документацию по интеграции TeamCity с AI для получения информации о правах токена и вариантах подключения.
В Rider перейдите в Настройки (Settings) | Инструменты (Tools) | AI Assistant | Model Context Protocol (MCP) и добавьте подключение HTTP. Действительная конфигурация подключения должна выглядеть так:
Замените адрес сервера и заполнитель токена в своей частной локальной конфигурации. Не храните токен в файлах, которые вы коммитите или отправляете в общий доступ. Примените конфигурацию и убедитесь, что Rider может установить соединение. Настройки подключения описаны в нашем руководстве по AI Assistant MCP.
Если вы используете Claude Agent, также откройте Настройки (Settings) | Инструменты (Tools) | AI Assistant | Агенты (Agents) и включите параметр Pass custom MCP servers. Затем выберите Claude Agent в AI-чате. Это предоставит агенту доступ к настроенному соединению, как описано в документации по Claude Agent.
Поручите агенту исследовать проблему
Опишите агенту симптомы и укажите сборку. Для аналогичного исследования вы можете адаптировать следующий промпт:
Замените ID перед отправкой промпта. Прикрепите соответствующий YAML-файл конвейера и скрипт сборки Unity, если агенту потребуется помощь с их поиском. TeamCity MCP предоставляет информацию о CI, а агент для написания кода использует IDE и файловые инструменты для проверки локального проекта.
В записи Claude определяет вариант диагностической сборки (diagnostic build flavor) и связывает его с неожиданным поведением игры. Он также замечает, что исправление уже было зафиксировано. Эта часть демо происходит после расследования Артема с помощью CLI и ручного исправления, поэтому ответ может ссылаться на это существующее изменение.
Проверьте доказательства в ответе. Ссылается ли он на запуск, о котором вы спрашивали? Соответствует ли значение параметра логам? Подходит ли объяснение к коду, который его использует? Эти проверки облегчают оценку предложенной причины, прежде чем вносить изменения в другой конвейер или проект.
Отслеживание нового развертывания
Затем Артем просит агента проверить новый конвейер и вернуть URL-адрес промежуточной среды (staging URL) после завершения развертывания. Агент опрашивает TeamCity во время активного сеанса и сообщает о ходе выполнения.
Последующий запрос может выглядеть так:
Для непрерывного обновления терминала вы также можете следить за запуском развертывания с помощью CLI:
Здесь 12346 представляет ID сборки нового развертывания. Используйте ID из вашего собственного конвейера. Как только он завершится, изучите его лог, если вам нужно получить URL-адрес:
Проверка развернутой игры
Откройте URL-адрес промежуточной среды и повторите взаимодействие, которое выявило проблему. В демо-версии Артема лунный пейзаж снова виден, и игрок может ездить по нему, как и ожидалось.
Эта проверка подтверждает, что изменение конфигурации решило наблюдаемую проблему. Предыдущий запуск уже был успешным (green), поэтому один лишь успешный результат конвейера не доказывает, что фон вернулся.
Для своего собственного проекта также убедитесь, что вы просматриваете развертывание из нового запуска. Затем сравните результат с локальной версией, которая работала правильно.
Упрощение следующего расследования
Пример предлагает несколько полезных улучшений для конвейера:
- Логируйте выбранный вариант сборки (build flavor) и другие настройки, которые влияют на вывод игры, чтобы их было легко найти.
- Проверяйте допустимые варианты для промежуточных сборок в скрипте сборки вашего проекта и убедитесь, что запуск завершается с ошибкой на раннем этапе, если значение является неожиданным.
- Добавьте проверку поведения, которое здесь пошло не так. В зависимости от проекта это может быть дымовое тестирование WebGL, которое загружает соответствующую сцену, или визуальная проверка развернутой игры.
Начните с отсутствующей проверки, которая могла бы выявить эту конкретную проблему. Это даст вам конкретный способ улучшить конвейер, а также повторяемый метод для исследования его результатов в Rider.
