Привет, Хабр! Недавно мы выпустили новую версию TeamCity – 2018.1. Это первый крупный релиз нашего СI/CD сервера в этом году. И в нем есть, на что посмотреть.
Полный список изменений, как всегда, внушительный. Но здесь мы остановимся на четырех главных фичах релиза. Поехали!
У TeamCity есть свой DSL (Domain-Specific Language), с помощью которого можно описывать настройки проектов и билд конфигураций в коде на языке Kotlin, воплощая в жизнь принципы Infrastructure as Code. В 2018.1 мы значительно переработали формат этого DSL, сделав его проще, удобнее и функциональнее.
Проще. Формат DSL был упрощен засчет того, что TeamCity теперь не нужны uuid сервера и ID проекта, он научился генерировать их самостоятельно из имени проектов и билд конфигураций. Вот, например, весь код, необходимый для описания простого “Hello world” проекта в TeamCity:
Один файл. Весь код для описания настроек TeamCity теперь хранится в одном файле — settings.kts, который надо добавить в директорию .teamcity.
Переносимость. Так как в коде теперь нет никакой привязки к конкретному серверу или проекту, его можно переиспользовать для других инсталляций или проектов в рамках одного сервера. Достаточно скопировать settings.kts в соответствующий репозиторий.
Создание проектов из URL. Чтобы TeamCity прочитал и применил настройки из кода, достаточно указать ему ссылку на репозиторий с .teamcity/settings.kts. Все описанные настройки будут исполнены автоматически.
Вот короткое демо новых возможностей Kotlin DSL от antonarhipov (на английском):
В 2018.1 появилась возможность запустить сервер в режиме read-only. Это позволяет настроить высокодоступный TeamCity кластер, состоящий из двух TeamCity серверов: основного и запасного, работающего в read-only режиме. Read-only сервер при этом будет иметь read доступ к базе данных и data directory, и будет постоянно подкачивать модификации данных, выполняемые основным сервером. В случае отказа основного сервера, read-only сервер примет на себя все запросы. Важно понимать, что read-only сервер сможет только показать последнее состояние на момент краха основного сервера, но не даст возможности это состояние менять.
Это актуально для крупных инсталляций, которым важно иметь бесперебойный доступ к CI серверу, как во время назапланированных сбоев, так и во время плановых обновлений.
Раньше мы уже писали про то, что TeamCity поддерживает Docker “из коробки”: запуск билдов в контейнере, создание Docker образов, их добавление и удаление из хранилища, запуск Docker команд, Docker compose.
В этом релизе добавлена поддержка .NET CLI и Powershell раннеров, что позволяет выполнять эти шаги сборки внутри Docker контейнера.
Также обновлен и сам Docker раннер: в нем нативно поддерживаются команды build, push и другие.
Как работает поддержка Docker в TeamCity, можно посмотреть в этом видео:
TeamCity AWS S3 плагин уже существовал какое-то время, но в версии 2018.1 мы устранили множество проблем и включили его в основную поставку. S3 интеграция настолько элегантно обрабатывает артефакт зависимости и clean-up артефактов и так встроена в UI TeamCity, что ничего не подозревающий пользователь может и не заметить, что артефакты хранятся в S3 бакете.
Вот демо:
В числе других улучшений стоит отметить более удобную работу с шагами сборки, унаследованными из шаблонов. В частности, теперь можно в шаблоне задать pre и post шаги, и указать, что шаги конфигурации попадают между ними.
В новой версии также существенно улучшена работа с NuGet feed. Теперь он может быть включён на уровне конкретного проекта, а не глобально на весь сервер, что вызывало проблемы с производительностью в прошлом. Как следствие, теперь поддерживается несколько NuGet feed в разных проектах.
Если какие-то из ваших сервисов в сети работают за SSL сертификатами, которые не подписаны известным authority, то вместо довольно сложного процесса импорта таких сертификатов в Java сервера и агентов, вы можете просто залить их в корневой проект сервера, через удобный веб интерфейс. И сервер и агенты тут же начнут использовать новые сертификаты.
У нас недавно прошел вебинар, в ходе которого antonarhipov демонстрировал всё вышеперечисленное в действии. Его можно посмотреть в записи:
Загрузить (а также запустить на AWS, в Azure или из Docker контейнера) последнюю версию TeamCity 2018.1 можно с нашего сайта. Замечания и предложения по новой версии оставляйте в нашем баг-трекере.
Полный список изменений, как всегда, внушительный. Но здесь мы остановимся на четырех главных фичах релиза. Поехали!
Новый TeamCity Kotlin DSL
У TeamCity есть свой DSL (Domain-Specific Language), с помощью которого можно описывать настройки проектов и билд конфигураций в коде на языке Kotlin, воплощая в жизнь принципы Infrastructure as Code. В 2018.1 мы значительно переработали формат этого DSL, сделав его проще, удобнее и функциональнее.
Проще. Формат DSL был упрощен засчет того, что TeamCity теперь не нужны uuid сервера и ID проекта, он научился генерировать их самостоятельно из имени проектов и билд конфигураций. Вот, например, весь код, необходимый для описания простого “Hello world” проекта в TeamCity:
version = "2018.1"
project{
buildType(HelloWorld)
}
object HelloWorld : BuildType({
name = "Hellow world"
steps {
scriptContent = "echo 'Hello world!'"
}
})
Один файл. Весь код для описания настроек TeamCity теперь хранится в одном файле — settings.kts, который надо добавить в директорию .teamcity.
Переносимость. Так как в коде теперь нет никакой привязки к конкретному серверу или проекту, его можно переиспользовать для других инсталляций или проектов в рамках одного сервера. Достаточно скопировать settings.kts в соответствующий репозиторий.
Создание проектов из URL. Чтобы TeamCity прочитал и применил настройки из кода, достаточно указать ему ссылку на репозиторий с .teamcity/settings.kts. Все описанные настройки будут исполнены автоматически.
Вот короткое демо новых возможностей Kotlin DSL от antonarhipov (на английском):
High Availability и режим read-only
В 2018.1 появилась возможность запустить сервер в режиме read-only. Это позволяет настроить высокодоступный TeamCity кластер, состоящий из двух TeamCity серверов: основного и запасного, работающего в read-only режиме. Read-only сервер при этом будет иметь read доступ к базе данных и data directory, и будет постоянно подкачивать модификации данных, выполняемые основным сервером. В случае отказа основного сервера, read-only сервер примет на себя все запросы. Важно понимать, что read-only сервер сможет только показать последнее состояние на момент краха основного сервера, но не даст возможности это состояние менять.
Это актуально для крупных инсталляций, которым важно иметь бесперебойный доступ к CI серверу, как во время назапланированных сбоев, так и во время плановых обновлений.
Улучшенная поддержка Docker
Раньше мы уже писали про то, что TeamCity поддерживает Docker “из коробки”: запуск билдов в контейнере, создание Docker образов, их добавление и удаление из хранилища, запуск Docker команд, Docker compose.
В этом релизе добавлена поддержка .NET CLI и Powershell раннеров, что позволяет выполнять эти шаги сборки внутри Docker контейнера.
Также обновлен и сам Docker раннер: в нем нативно поддерживаются команды build, push и другие.
Как работает поддержка Docker в TeamCity, можно посмотреть в этом видео:
Хранение артефактов в Amazon S3
TeamCity AWS S3 плагин уже существовал какое-то время, но в версии 2018.1 мы устранили множество проблем и включили его в основную поставку. S3 интеграция настолько элегантно обрабатывает артефакт зависимости и clean-up артефактов и так встроена в UI TeamCity, что ничего не подозревающий пользователь может и не заметить, что артефакты хранятся в S3 бакете.
Вот демо:
Другие улучшения
В числе других улучшений стоит отметить более удобную работу с шагами сборки, унаследованными из шаблонов. В частности, теперь можно в шаблоне задать pre и post шаги, и указать, что шаги конфигурации попадают между ними.
В новой версии также существенно улучшена работа с NuGet feed. Теперь он может быть включён на уровне конкретного проекта, а не глобально на весь сервер, что вызывало проблемы с производительностью в прошлом. Как следствие, теперь поддерживается несколько NuGet feed в разных проектах.
Если какие-то из ваших сервисов в сети работают за SSL сертификатами, которые не подписаны известным authority, то вместо довольно сложного процесса импорта таких сертификатов в Java сервера и агентов, вы можете просто залить их в корневой проект сервера, через удобный веб интерфейс. И сервер и агенты тут же начнут использовать новые сертификаты.
У нас недавно прошел вебинар, в ходе которого antonarhipov демонстрировал всё вышеперечисленное в действии. Его можно посмотреть в записи:
Загрузить (а также запустить на AWS, в Azure или из Docker контейнера) последнюю версию TeamCity 2018.1 можно с нашего сайта. Замечания и предложения по новой версии оставляйте в нашем баг-трекере.
Напоминаем, что TeamCity Professional предоставляет 100 билд конфигураций и 3 билд агента совершенно бесплатно, без ограничений по времени и функциональности.Удачных сборок!
