Настройка CI/CD пайплайна через TeamCity: Kotlin DSL и облачные агенты

TeamCity настройка: где ломается конвейер сборки

Настройка TeamCity начинается не с экрана сборки, а с вопроса: сколько времени проходит от коммита до рабочего стенда. Если ответ «час и больше», узкое место почти всегда на стыках — очередь агентов, ручные шаги между сборкой и выкаткой, разъехавшиеся окружения.

Медленная сборка редко объясняется слабым железом. Чаще один агент обслуживает несколько проектов, задания выстраиваются в очередь, и время ожидания сборки перевешивает саму компиляцию с тестами.

Ручные шаги в релизе — вторая точка потерь. Пока артефакт переносят вручную или ждут того, кто знает, что нажать, доставка изменений идёт рывками: в конце недели никто не рискует, а к началу следующей копится пачка правок, которую сложнее проверить.

Невоспроизводимость среды даёт самый дорогой класс отказов: локально всё зелёное, на агенте — нет. Разные версии инструментов, прогретые кэши и переменные окружения превращают разбор в перебор гипотез.

Отдельно — нестабильные проверки. Тест, падающий через раз, приучает команду не смотреть на красный статус, и настоящая поломка уходит в основную ветку вместе с ним.

Поэтому мы смотрим на конвейер как на систему: где он ждёт, где зависит от человека и где результат не повторяется. Ниже разбираем, как это закрывается — от конфигурации, описанной кодом на Kotlin DSL, до облачных агентов, которые масштабируются под нагрузку.

TeamCity настройка: что меняется в скорости и надёжности

Настройка TeamCity начинается не с установки сервера, а с инвентаризации того, что в проекте до сих пор делается руками. Дальше сборка описывается кодом на Kotlin DSL, а тяжёлые шаги уезжают на облачные агенты: они поднимаются под нагрузку и не простаивают между релизами.

Как сокращается время проверок изменений

Кеширование зависимостей и артефактов между запусками и распараллеливание независимых шагов сокращают время сборки в разы — проверка изменений на типовом сервисе уходит с десятков минут к единицам. Разработчик получает результат по своей ветке, не дожидаясь общей очереди на единственном агенте, поэтому очередь сборок перестаёт быть узким местом при росте команды.

Как уходит класс отказов из ручных операций

Ручной шаг ломает релиз одинаково предсказуемо: забыли миграцию, собрали из неверной ветки, развернули не ту конфигурацию. Каждое такое действие становится шагом сборочной цепочки с проверками до выката — доля ручных операций падает, а стабильность релизов растёт без ночных дежурств.

Итог измерим: время сборки и скорость проверок изменений сокращаются, простой команды из-за сломанных сборок уходит, откат на предыдущий артефакт становится обычной операцией.

Облачные и собственные агенты сборки: выбор режима работы

Агент — это машина, которая фактически выполняет шаги сборки, и от режима её работы зависят и время ожидания в очереди, и поведение конвейера на пиках. TeamCity управляет облачными и собственными агентами одинаково, поэтому смена режима — вопрос конфигурации, а не переписывания сборочных сценариев.

Когда нужен собственный парк агентов

Свои машины оправданы, если сборке нужен доступ в закрытый контур, локальный реестр или стенд без внешнего адреса. Второй признак — устойчивый поток: если в рабочие часы агенты заняты постоянно, парк даёт предсказуемое время постановки в очередь. Заодно решается изоляция сборочных сред: пулы закрепляются за командой или типом задач, и чужая сборка не отбирает ресурсы у вашей.

Как считается пиковая нагрузка на сборки

Пиковую нагрузку считаем по журналу запусков: график одновременных сборок за характерный период, верхний процентиль вместо среднего и запас на рост числа команд. Дальше сопоставляем с числом агентов и временем удержания — видно, сколько машин не хватает в худшем окне и сколько простаивает обычно. Для гибридной схемы тот же расчёт задаёт порог, после которого задачи автоматически уходят в облачный пул.

Этапы работ: от аудита сборок до передачи регламентов

Работы идут так, чтобы сборки оставались рабочими на каждом шаге: сначала фиксируем текущее состояние, затем переносим описания сборок в код и только после проверки на копии продакшена переводим команду на новый конвейер в TeamCity. Последовательность этапов не зависит от размера проекта — меняется объём, не порядок.

1. Аудит сборок — инвентаризация конфигураций, замер времени каждой сборки, поиск дублирующихся проверок и шагов, зависящих от состояния конкретного агента.
2. Перенос описаний сборок в Kotlin DSL — конфигурации становятся кодом: правка проходит проверку перед слиянием, откат делается возвратом предыдущей редакции файла.
3. Схема окружений — какие ветки во что собираются, где лежат артефакты, какие права у учётных записей и откуда берутся секреты.
4. Облачные агенты — пулы под типы задач, автомасштабирование против очереди в пик, изоляция агентов друг от друга.
5. Проверка на копии продакшена — полный путь сборки и выкладки прогоняем на копии и сверяем с текущим конвейером.
6. Передача регламентов — как добавить шаг, откатить выпущенную версию и что делать при падении агента.

Схема окружений и перенос описаний сборок

Схема отвечает на вопрос, что где запускается и куда попадает результат: репозитории, пулы агентов, артефакты, права. Пока она не согласована, перенос описаний в код превращается в переписывание одной и той же логики под каждый проект.

Проверка на копии продакшена

Копия повторяет конфигурацию рабочих серверов, поэтому на ней видны расхождения в переменных окружения и сервисы, недоступные из агента. Переключение делаем только после того, как старый и новый конвейеры дают совпадающий результат.

Что остаётся у вас: конфигурации, схемы, регламенты

Внедрение заканчивается не отчётом, а набором рабочих артефактов в вашем контуре. Конфигурации TeamCity, схемы окружений и регламенты остаются у вас в виде читаемых файлов и документов, а не закрытого архива — их можно править и передавать новому инженеру без нас.

Всё лежит в вашей системе контроля версий рядом с кодом: изменения проходят ревью и откатываются как обычный коммит.

• Конфигурация сборок — описания на Kotlin DSL в вашем репозитории: шаги, триггеры, зависимости между сборками, параметры окружений. Правки идут через ветку и ревью, а не через веб-интерфейс.
• Документация по сборкам — что делает каждый шаг, какие артефакты он отдаёт, какие проверки обязательны перед выкладкой.
• Схема окружений — какие среды есть, чем отличаются, куда смотрит каждая ветка и как артефакт продвигается до промышленного контура.
• Политики доступа — роли и права: кто запускает сборку, кто утверждает выкладку, какие агенты к каким хранилищам допущены. Плюс порядок выдачи и отзыва доступов.
• Регламент сопровождения — как добавить шаг, обновить агент, почистить кэш и откатить релиз, с явной границей ответственности между вами и нами.
• Инструкция по подключению облачных агентов — как поднять новый агент, какие у него метки и лимиты, как проверить, что он попал в нужный пул.

Такая передача снимает главный риск — зависимость от человека, который «знает, как тут всё устроено». Конфигурация версионируется, политики описаны, регламент проверен на живых релизах, а не написан по памяти.

Кейс: сократили время сборки и убрали ручные шаги

Проект — монорепозиторий на четыре команды: сервисы на Kotlin, общая библиотека, мобильная сборка. Конвейер жил в TeamCity, но настраивался через веб-интерфейс: шаги правились руками, конфигурации дублировались между проектами, изменения никто не ревьюил.

Что было до

Сборка занимала 24–28 минут: половина шагов шла последовательно, хотя не зависела друг от друга. Релиз собирали вручную — 11 операций от простановки тега до правки переменных окружения, каждая по 3–4 минуты и с опорой на память ответственного.

Ошибки были предсказуемы: забытый тег, не тот профиль сборки, разъехавшиеся конфигурации. Каждая третья сборка на основной ветке падала, а разбор занимал больше 20 минут — в логе смешивались шаги всех проектов.

Как измеряли результат и что считали отказом

Метрики снимали из истории сборок за 60 рабочих дней до и после: медиана длительности успешной сборки, доля падений на основной ветке, число ручных операций в чек-листе релиза, время от коммита до публикации артефакта.

Отказом считали любое падение не из-за кода: недоступный агент, конфликт версий зависимостей, неверный параметр окружения. Падения по вине разработчика считали отдельно — иначе метрика мерила бы качество кода, а не конвейера.

Описание сборки перевели в Kotlin DSL в репозитории, агенты сделали облачными и на одно задание, шаги распараллелили до шести и добавили кэш зависимостей. Медиана сборки — 8 минут, доля падений — 4%, ручных операций в релизе — одна, от коммита до артефакта — 14 минут.

Kotlin DSL или сборка через веб-интерфейс: что выбрать?

Короткий ответ: если конвейер меняется чаще пары раз в квартал и над ним работают несколько инженеров — описывайте сборку кодом на Kotlin DSL. Если конфигурация стабильна и её правит один человек, веб-интерфейса TeamCity достаточно: репозиторий настроек добавит работы без отдачи.

В Kotlin DSL описание сборки лежит в том же репозитории, что и код. Любое изменение — шаг, зависимость, параметр агента — приходит через запрос на слияние: видно построчно, что и зачем поменяли и кто согласовал, а откат возвращает прежнее состояние из истории. Версионирование конфигурации и ревью изменений сборки перестают быть договорённостью на словах — они встроены в процесс.

Веб-интерфейс выигрывает в скорости: настройка кликами быстрее для однотипных проектов, история правок хранится внутри системы, и небольшой команде этого хватает. Ограничение проявляется на росте: общие шаблоны дублируются руками, а понять, почему сборка ведёт себя иначе, чем полгода назад, можно только по журналу внутри сервера.

Переходить можно постепенно, без переписывания всего сразу. Проект остаётся в веб-интерфейсе, а в код выносится общее: шаблоны, параметры окружений, правила запуска. Затем по одному переносятся конвейеры — с проверкой, что поведение сборки не изменилось.

Критерий простой: много проектов, веток и обязательное согласование правок — Kotlin DSL; один-два стабильных конвейера и один ответственный — веб-интерфейс. Смешанный режим тоже рабочий: он наращивает практику версионирования конфигурации там, где она даёт эффект.

Частые сомнения: доступы, секреты, откат сборки

Сомнения, которые чаще всего всплывают до старта, почти всегда про одно: что будет, если что-то сломается или утечёт. Ниже — пять вопросов, которые мы разбираем с заказчиком до первого коммита в TeamCity, и наши ответы по умолчанию.

Как разведены окружения, чтобы тест не уехал в прод?

Под каждую среду — свой набор переменных и ключей доступа, а выкладка в прод идёт только из защищённой ветки и с подтверждением ответственного. Артефакт собирается один раз и продвигается между средами, а не пересобирается заново: то, что прошло проверки, попадает в прод без изменений. Так «работает на тесте, падает в проде» перестаёт быть классом отказов.

Что доступно агентам сборки и остаётся ли что-то после сборки?

Агент получает только те параметры, которые нужны текущему шагу, и отдельный ключ на чтение репозитория — без права писать. Облачные агенты создаются под задачу и удаляются после неё, поэтому между проектами и между запусками ничего не остаётся.

Как обновляются агенты и не встанет ли конвейер целиком?

Обновление идёт волной: сначала обновляется один агент и проверяется на небоевых сборках, затем остальные. Совместимость версии агента и сервера проверяем до массового обновления — иначе конвейер встаёт целиком, и это ровно тот отказ, который дороже всего по времени простоя.

Что делать, если описание сборки повреждено или кто-то его сломал?

История описания сборки хранится в системе контроля версий, поэтому откат — это revert коммита, а не ручная правка по памяти. Дополнительно держим последний рабочий артефакт и параметры его запуска: релиз можно пересобрать из того же коммита, даже если конвейер сломан.

Обсудим задачу: что нужно для оценки и плана работ

Чтобы вернуться с реалистичной оценкой и планом, а не с вилкой «от и до», нам нужен слепок вашей текущей инфраструктуры. По настройке TeamCity он даёт понимание объёма работ, этапов и рисков — что можно вынести в облачные агенты, что придётся оставить на своих машинах и как пройти переход без остановки релизов.

• Инвентаризация сборок: сколько конфигураций и проектов в контуре, какие языки и рантаймы, где хранятся артефакты, какие сборки уже не используются и их можно вывести.
• Текущий сборочный конвейер: чем запускается, какие стадии проходит код от коммита до продакшена, где остаются ручные шаги и ручные подтверждения.
• Требования к доступам: роли в репозиториях и реестре образов, где лежат секреты и кто их владелец, нужен ли отдельный сетевой контур для сборочных агентов.
• Среда исполнения: свои агенты или облачные, какие лицензии и квоты уже есть, есть ли ограничения по сети, хранилищу и длительности сборки.
• Критерии готовности: что считаем результатом — время сборки, доля проверок, которые проходят автоматически, и возможность отката на предыдущий артефакт в один шаг.
• Порядок передачи: кто принимает работу, нужны ли регламенты и инструкции для вашей команды, кто отвечает за конвейер после запуска.

Опишите задачу в свободной форме — по этим пунктам или как удобно. Мы вернёмся с оценкой, планом этапов и сроками, а спорные места по миграции и доступам разберём отдельно.