Привет, Хабр! На прошлой неделе мы выпустили TeamCity 2020.1 — новую версию CI/CD-сервера от JetBrains. В этом посте я хочу рассказать, что в ней появилось интересного.
Запрос Execute a build step based on a condition был создан в нашем баг-трекере 9 лет назад, и по количеству голосов он много лет держал однозначное лидерство. И вот, наконец, мы реализовали эту функцию! Теперь вы можете задавать условия запуска отдельных шагов сборки.
Выглядит это примерно так:
TeamCity 2020.1 позволяет делать отдельные билд-шаги опциональными, и у этого может быть масса самых разных применений. Например, можно выполнять часть тестов только на выбранном агенте или только под заданной OS. Можно деплоить изменения на различные сервера, в зависимости от бранча. Можно выполнять различные command-line скрипты на различных платформах. И так далее.
Почему мы не сделали этого раньше? Потому что любые CI/CD пайплайны всегда можно было создать и без этого. TeamCity построен вокруг идеи, что каждая билд-конфигурация должна отвечать за одну конкретную задачу, без сложной логики внутри. Задеплоить на staging-сервер — один билд, задеплоить на production-сервер — другой. Хотите создать много однообразных билдов? Kotlin DSL и шаблоны вам в помощь.
Но жизнь показала, что многие пользователи ожидают от продукта другого поведения, и вместо создания цепочек из билдов хотят задавать условия выполнения отдельных шагов внутри билдов. Их просьбы, наконец, растопили наши сердца — надеемся, что теперь TeamCity станет для них понятнее и удобнее. Мы же со своей стороны будем внимательно наблюдать, как используется эта фича.
Пользуясь случаем, напомню, что все продукты JetBrains развиваются совершенно прозрачно, и для каждого из них доступен публичный баг-трекер. В нашем YouTrack вы всегда можете предложить что-то новое, зарепортить баг или добавить голос какому-то запросу.
Поддержка запуска билд-агентов в Kubernetes появилась в TeamCity ещё в 2017 году в виде отдельного плагина. В версии 2020.1 мы доработали этот плагин, исправили ряд багов и включили в основной дистрибутив, сделав доступным из коробки. Идея осталась всё та же: билд-агенты запускаются по необходимости, выполняют свою в работу, а затем удаляются после завершения сборки.
Уже два года мы активно развиваем возможность совместной работы нескольких установок TeamCity в режиме кластера. В версии 2020.1 расширился список обязанностей (responsibilities), которые могут быть назначены вторичным серверам, а также появилась возможность выполнять ряд действий пользовательского уровня в UI.
Начнём с новых обязанностей. Многие из наших клиентов имеют огромные инсталляции TeamCity с сотнями и тысячами триггеров, которые срабатывают при коммитах, появлении новых артефактов, по таймеру и т. д. Теперь к этому процессу можно подключить вторичный сервер и разгрузить основной.
Внутри JetBrains практически все продукты собираются при помощи TeamCity. На сегодняшний день у нас более 1100 билд-агентов, которые управляются двумя серверами. Раньше встречались ситуации, когда время обработки каких-то триггеров было больше, чем интервал между срабатываниями этих триггеров. Например, кому-то нужно было запускать сборку каждую минуту, но сервер не мог этого сделать, потому что соответствующий триггер обрабатывался раз в две минуты. После переключения обработки триггеров на вторичный сервер, эта проблема ушла.
Кроме обработки триггеров мы расширили интерфейс вторичного сервера: теперь он позволяет редактировать профиль пользователя, менять вид проектов и конфигураций и управлять билд-агентами. Это позволяет продолжать работать с TeamCity во время даунтайма основного сервера.
При подключении к серверу TeamCity билд-агенты первым делом проверяют собственную версию и актуальность установленных плагинов. Если находятся несовпадения, то запускается обновление, которое может занять значительное время (до нескольких минут). Чтобы облегчить жизнь пользователям, работающим с облачными билд-агентами, в версии 2020.1 добавлена возможность скачать готовый дистрибутив билд-агента, который не потребует обновления при подключении к серверу.
Для исправления падающих билдов TeamCity позволяет назначать инвестигации (investigations), чтобы кто-нибудь из команды изучил причину падения. Инвестигации позволяют понять, занимается ли кто-то сломанным билдом и каков текущий статус проблемы. В JetBrains этой функцией пользуются все команды без исключения, это неотъемлемая часть нашего процесса разработки.
Раньше мы часто сталкивались со следующей ситуацией. Падает сборка, ты начинаешь искать проблему и понимаешь, что где-то ты её уже видел. Начинаешь вспоминать, кто проводил инвестигацию в прошлый раз, в чём она заключалась и чем закончилась. Но поскольку такой информации нигде не хранится, приходится выяснять в чатиках.
В TeamCity 2020.1 мы добавили возможность посмотреть историю инвестигаций: кто её создал и каким образом она пришла к текущему состоянию. Это оказалось настолько полезно, что наш коллега lany отозвался об этой функции так:
Ранее TeamCity поддерживал только персональные уведомления: каждый пользователь мог зайти в настройки и выбрать, какие сообщения он хочет получать. В новой версии администраторы проектов могут настраивать уведомления сразу для всей команды. Делается это на уровне билд-конфигурации, что даёт возможность наследовать настройки подпроектами, а также редактировать, переиспользовать их и делиться ими с помощью Kotlin DSL.
На базе нового движка уведомлений мы разработали новую функциональность, которая позволяет получать уведомления о статусе сборок в Slack.
TeamCity умеет интегрироваться с Jira уже не один год: при упоминании задач в сообщениях коммита к ним автоматически добавляются ссылки на соответствующие задачи в Jira. В новой версии мы расширили интеграцию и начали отправлять информацию о состоянии билдов в Jira Software Cloud. Теперь для каждой задачи в Jira можно увидеть связанные с ней билды, когда они были собраны, и куда они были задеплоены.
Мы добавили поддержку пулл-реквестов Azure DevOps, расширив список VCS-хостингов, для которых работает функция Pull Requests. Теперь TeamCity позволяет автоматически собирать пулл-реквесты Azure DevOps — аналогично тому, как это работает с GitHub и GitLab.
Год назад мы выпустили новый экспериментальный интерфейс под кодовым названием “Sakura”, и за это время он отлично себя зарекомендовал. Он классный: выглядит свежо, работает быстро и построен на современных технологиях, что позволяет нам добавлять новые функции без тормозов.
Пока что Sakura ещё не поддерживает все-все сценарии, которые доступны в классическом интерфейсе. Однако мы вовсю движемся к этому. В версии 2020.1 мы обновили страницы Agents и Projects, а также добавили возможность кастомизировать боковую панель.
Это не все изменения новой версии! Полный список изменений можно прочитать в документации.
Дистрибутивы TeamCity 2020.1 можно скачать с нашего сайта. Также доступен Docker-образ TeamCity на Docker Hub.
Замечания и предложения по новой версии оставляйте в нашем баг-трекере.
Условия выполнения билд-шагов
Запрос Execute a build step based on a condition был создан в нашем баг-трекере 9 лет назад, и по количеству голосов он много лет держал однозначное лидерство. И вот, наконец, мы реализовали эту функцию! Теперь вы можете задавать условия запуска отдельных шагов сборки.
Выглядит это примерно так:
TeamCity 2020.1 позволяет делать отдельные билд-шаги опциональными, и у этого может быть масса самых разных применений. Например, можно выполнять часть тестов только на выбранном агенте или только под заданной OS. Можно деплоить изменения на различные сервера, в зависимости от бранча. Можно выполнять различные command-line скрипты на различных платформах. И так далее.
Почему мы не сделали этого раньше? Потому что любые CI/CD пайплайны всегда можно было создать и без этого. TeamCity построен вокруг идеи, что каждая билд-конфигурация должна отвечать за одну конкретную задачу, без сложной логики внутри. Задеплоить на staging-сервер — один билд, задеплоить на production-сервер — другой. Хотите создать много однообразных билдов? Kotlin DSL и шаблоны вам в помощь.
Но жизнь показала, что многие пользователи ожидают от продукта другого поведения, и вместо создания цепочек из билдов хотят задавать условия выполнения отдельных шагов внутри билдов. Их просьбы, наконец, растопили наши сердца — надеемся, что теперь TeamCity станет для них понятнее и удобнее. Мы же со своей стороны будем внимательно наблюдать, как используется эта фича.
Пользуясь случаем, напомню, что все продукты JetBrains развиваются совершенно прозрачно, и для каждого из них доступен публичный баг-трекер. В нашем YouTrack вы всегда можете предложить что-то новое, зарепортить баг или добавить голос какому-то запросу.
Запуск билд-агентов в кластере Kubernetes
Поддержка запуска билд-агентов в Kubernetes появилась в TeamCity ещё в 2017 году в виде отдельного плагина. В версии 2020.1 мы доработали этот плагин, исправили ряд багов и включили в основной дистрибутив, сделав доступным из коробки. Идея осталась всё та же: билд-агенты запускаются по необходимости, выполняют свою в работу, а затем удаляются после завершения сборки.
Мультисерверное масштабирование
Уже два года мы активно развиваем возможность совместной работы нескольких установок TeamCity в режиме кластера. В версии 2020.1 расширился список обязанностей (responsibilities), которые могут быть назначены вторичным серверам, а также появилась возможность выполнять ряд действий пользовательского уровня в UI.
Начнём с новых обязанностей. Многие из наших клиентов имеют огромные инсталляции TeamCity с сотнями и тысячами триггеров, которые срабатывают при коммитах, появлении новых артефактов, по таймеру и т. д. Теперь к этому процессу можно подключить вторичный сервер и разгрузить основной.
Внутри JetBrains практически все продукты собираются при помощи TeamCity. На сегодняшний день у нас более 1100 билд-агентов, которые управляются двумя серверами. Раньше встречались ситуации, когда время обработки каких-то триггеров было больше, чем интервал между срабатываниями этих триггеров. Например, кому-то нужно было запускать сборку каждую минуту, но сервер не мог этого сделать, потому что соответствующий триггер обрабатывался раз в две минуты. После переключения обработки триггеров на вторичный сервер, эта проблема ушла.
Кроме обработки триггеров мы расширили интерфейс вторичного сервера: теперь он позволяет редактировать профиль пользователя, менять вид проектов и конфигураций и управлять билд-агентами. Это позволяет продолжать работать с TeamCity во время даунтайма основного сервера.
Возможность загрузить готовый дистрибутив билд-агента
При подключении к серверу TeamCity билд-агенты первым делом проверяют собственную версию и актуальность установленных плагинов. Если находятся несовпадения, то запускается обновление, которое может занять значительное время (до нескольких минут). Чтобы облегчить жизнь пользователям, работающим с облачными билд-агентами, в версии 2020.1 добавлена возможность скачать готовый дистрибутив билд-агента, который не потребует обновления при подключении к серверу.
История инвестигаций
Для исправления падающих билдов TeamCity позволяет назначать инвестигации (investigations), чтобы кто-нибудь из команды изучил причину падения. Инвестигации позволяют понять, занимается ли кто-то сломанным билдом и каков текущий статус проблемы. В JetBrains этой функцией пользуются все команды без исключения, это неотъемлемая часть нашего процесса разработки.
Раньше мы часто сталкивались со следующей ситуацией. Падает сборка, ты начинаешь искать проблему и понимаешь, что где-то ты её уже видел. Начинаешь вспоминать, кто проводил инвестигацию в прошлый раз, в чём она заключалась и чем закончилась. Но поскольку такой информации нигде не хранится, приходится выяснять в чатиках.
В TeamCity 2020.1 мы добавили возможность посмотреть историю инвестигаций: кто её создал и каким образом она пришла к текущему состоянию. Это оказалось настолько полезно, что наш коллега lany отозвался об этой функции так:
“Whoever created the investigation history table, thank you very much! It's the most useful addition to TeamCity during the last year!”Надеемся, что и вам она придётся по душе!
Уведомления на уровне проектов
Ранее TeamCity поддерживал только персональные уведомления: каждый пользователь мог зайти в настройки и выбрать, какие сообщения он хочет получать. В новой версии администраторы проектов могут настраивать уведомления сразу для всей команды. Делается это на уровне билд-конфигурации, что даёт возможность наследовать настройки подпроектами, а также редактировать, переиспользовать их и делиться ими с помощью Kotlin DSL.
На базе нового движка уведомлений мы разработали новую функциональность, которая позволяет получать уведомления о статусе сборок в Slack.
Новые интеграции
Jira Software Cloud
TeamCity умеет интегрироваться с Jira уже не один год: при упоминании задач в сообщениях коммита к ним автоматически добавляются ссылки на соответствующие задачи в Jira. В новой версии мы расширили интеграцию и начали отправлять информацию о состоянии билдов в Jira Software Cloud. Теперь для каждой задачи в Jira можно увидеть связанные с ней билды, когда они были собраны, и куда они были задеплоены.
Azure DevOps
Мы добавили поддержку пулл-реквестов Azure DevOps, расширив список VCS-хостингов, для которых работает функция Pull Requests. Теперь TeamCity позволяет автоматически собирать пулл-реквесты Azure DevOps — аналогично тому, как это работает с GitHub и GitLab.
Новый интерфейс “Sakura”
Год назад мы выпустили новый экспериментальный интерфейс под кодовым названием “Sakura”, и за это время он отлично себя зарекомендовал. Он классный: выглядит свежо, работает быстро и построен на современных технологиях, что позволяет нам добавлять новые функции без тормозов.
Пока что Sakura ещё не поддерживает все-все сценарии, которые доступны в классическом интерфейсе. Однако мы вовсю движемся к этому. В версии 2020.1 мы обновили страницы Agents и Projects, а также добавили возможность кастомизировать боковую панель.
Это не все изменения новой версии! Полный список изменений можно прочитать в документации.
Дистрибутивы TeamCity 2020.1 можно скачать с нашего сайта. Также доступен Docker-образ TeamCity на Docker Hub.
Замечания и предложения по новой версии оставляйте в нашем баг-трекере.
Напомню, что у нас есть бесплатная версия TeamCity Professional, которая отлично подойдёт большинству разработчиков. В ней всего два ограничения: она позволяет создавать не более 100 билд-конфигураций и запускать не более 3 параллельных билдов. В остальном она не отличается от TeamCity Enterprise.Удачных сборок!
