company_banner

TeamCity 2018.1: новый Kotlin DSL, режим High Availability, улучшенная Docker интеграция и Amazon S3 из коробки

    Привет, Хабр! Недавно мы выпустили новую версию TeamCity – 2018.1. Это первый крупный релиз нашего СI/CD сервера в этом году. И в нем есть, на что посмотреть.

    Полный список изменений, как всегда, внушительный. Но здесь мы остановимся на четырех главных фичах релиза. Поехали!



    Новый 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 билд агента совершенно бесплатно, без ограничений по времени и функциональности.
    Удачных сборок!

    JetBrains

    163,18

    Делаем эффективные инструменты для разработчиков

    Поделиться публикацией
    Комментарии 0

    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

    Самое читаемое