Bonjour, Habr! Nous avons récemment publié une nouvelle version de TeamCity - 2018.1. Il s'agit de la première version majeure de notre serveur CI / CD cette année. Et il y a quelque chose à regarder.
La liste complète des changements est, comme toujours,
impressionnante . Mais ici, nous nous concentrerons sur quatre caractéristiques principales de la version. C'est parti!
Nouvelle TeamCity Kotlin DSL
TeamCity possède son propre DSL (Domain-Specific Language), avec lequel vous pouvez décrire les paramètres des projets et créer des configurations en code Kotlin, incarnant les principes de l'infrastructure en tant que code. En 2018.1, nous avons considérablement retravaillé le format de ce DSL, le rendant plus simple, plus pratique et plus fonctionnel.
Plus simple . Le format DSL a été simplifié du fait que TeamCity n'a plus besoin d'un serveur uuid et d'un ID de projet, il a appris à les générer indépendamment du nom des projets et des configurations de build. Voici, par exemple, tout le code nécessaire pour décrire un simple projet «Hello world» dans TeamCity:
version = "2018.1" project{ buildType(HelloWorld) } object HelloWorld : BuildType({ name = "Hellow world" steps { scriptContent = "echo 'Hello world!'" } })
Fichier unique . Tout le code pour décrire les paramètres TeamCity est maintenant stocké dans un fichier - settings.kts, qui doit être ajouté au répertoire .teamcity.
Portabilité . Étant donné que le code n'a plus de liaison avec un serveur ou un projet spécifique, il peut être réutilisé pour d'autres installations ou projets au sein du même serveur. Copiez simplement settings.kts dans le référentiel approprié.
Créez des projets à partir d'une URL . Pour que TeamCity puisse lire et appliquer les paramètres du code, il suffit de lui donner un lien vers le référentiel avec .teamcity / settings.kts. Tous les paramètres décrits seront exécutés automatiquement.
Voici une courte démonstration des nouvelles fonctionnalités Kotlin DSL d'
Antonarhipov (en anglais):
Haute disponibilité et lecture seule
En 2018.1, il est devenu possible de démarrer le serveur en mode lecture seule. Cela vous permet de configurer un cluster TeamCity hautement accessible, composé de deux serveurs TeamCity: le serveur principal et le serveur de secours, fonctionnant en mode lecture seule. Dans ce cas, le serveur en lecture seule aura un accès en lecture à la base de données et au répertoire de données, et pompera constamment les modifications de données effectuées par le serveur principal. En cas de panne du serveur principal, le serveur en lecture seule acceptera toutes les demandes. Il est important de comprendre que le serveur en lecture seule ne pourra afficher que le dernier état au moment de l'effondrement du serveur principal, mais il ne permettra pas à cet état de changer.
Cela est vrai pour les grandes installations, qui sont importantes pour avoir un accès ininterrompu au serveur CI, à la fois pendant les échecs planifiés et pendant les mises à jour planifiées.
Prise en charge améliorée de Docker
Nous avons déjà écrit sur le fait que TeamCity prend en charge Docker «prêt à l'emploi»: lancement de builds dans le conteneur, création d'images Docker, ajout et suppression de celles-ci du référentiel, lancement de commandes Docker, composition Docker.
Cette version ajoute la prise en charge des exécuteurs CLI .NET et Powershell, ce qui vous permet d'effectuer ces étapes de génération dans le conteneur Docker.
Le runner Docker lui-même a également été mis à jour: il prend en charge nativement la génération, la transmission et d'autres.
Comment fonctionne le support Docker dans TeamCity, vous pouvez le voir dans cette vidéo:
Stocker des artefacts sur Amazon S3
Le plugin TeamCity AWS S3 existe déjà depuis un certain temps, mais dans la version 2018.1, nous avons corrigé de nombreux problèmes et l'avons inclus dans la distribution principale. L'intégration S3 gère les artefacts de dépendance et les artefacts de nettoyage de manière si élégante et est tellement intégrée dans TeamCity UI qu'un utilisateur sans méfiance peut ne pas remarquer que les artefacts sont stockés dans le compartiment S3.
Voici une démo:
Autres améliorations
Entre autres améliorations, il convient de noter un travail plus pratique avec les étapes d'assemblage héritées des modèles. En particulier, il est désormais possible de définir des étapes pré et post dans le modèle et d'indiquer que les étapes de configuration se situent entre elles.
La nouvelle version a également considérablement amélioré le travail avec le flux NuGet. Désormais, il peut être activé au niveau d'un projet spécifique, et non globalement sur l'ensemble du serveur, ce qui a provoqué des problèmes de performances dans le passé. Par conséquent, plusieurs flux NuGet dans différents projets sont désormais pris en charge.
Si certains de vos services sur le réseau fonctionnent pour des certificats SSL qui ne sont pas signés par une autorité bien connue, alors au lieu du processus plutôt compliqué d'importation de tels certificats dans des serveurs et des agents Java, vous pouvez simplement les télécharger sur le projet de serveur racine via une interface Web pratique. Le serveur et les agents commenceront immédiatement à utiliser les nouveaux certificats.
Nous avons récemment
organisé un webinaire au cours duquel
antonarhipov a démontré tout ce qui précède en action. Vous pouvez le voir dans l'entrée:
Vous pouvez télécharger (ainsi qu'exécuter sur AWS, dans Azure ou à partir du conteneur Docker) la dernière version de TeamCity 2018.1 à partir de notre
site Web . Laissez des commentaires et suggestions sur la nouvelle version dans notre
outil de suivi des bogues .
Nous vous rappelons que TeamCity Professional fournit 100 versions de configurations et 3 versions d'agent absolument gratuitement , sans restrictions de temps et de fonctionnalité.
Ayez une belle construction!