Nouveautés de TeamCity 2020.1

TeamCity 2020.1 propose des étapes de build conditionnelles, permet de lancer des agents de build dans un cluster Kubernetes et s’intègre avec Azure DevOps et Jira Software Cloud. Il ajoute des fonctionnalités aux serveurs secondaires dans une configuration multinœuds, intègre un nouvel outil de notifications Slack et apporte de nombreuses améliorations appréciables à l’interface utilisateur expérimentale.

Étapes de build conditionnelles pour une polyvalence inconditionnelle

Étapes de build conditionnelles pour une polyvalence inconditionnelle

Avez-vous déjà voulu exécuter différents scripts de ligne de commande sur différentes plateformes ou déployer des modifications dans plusieurs branches sur différents serveurs de transfert ? Maintenant, vous êtes libre de faire un peu tout ce que vous voulez ! TeamCity 2020.1 vous permet de spécifier des conditions pour vos étapes de build et de ne les exécuter que si les critères sont remplis.

Build évolutive dans un cluster. Merki Kub.

Build évolutive dans un cluster. Merki Kub.

Des déploiements de clusters simples et reproductibles sont désormais disponibles prêts à l’emploi. La version 2020.1 vous permet d’implémenter une architecture CI/CD évolutive par-dessus Kubernetes : les agents de build peuvent être lancés automatiquement lorsque vous en avez besoin, faire leur travail, puis être supprimés une fois la build terminée.

Magie multi-serveur

Magie multi-serveur

Faire fonctionner plusieurs serveurs TeamCity, et les faire fonctionner ensemble peut élever votre CI/CD à un tout nouveau degré de performances et de fiabilité. Nous avons amélioré le fonctionnement de TeamCity dans un environnement de clustering en étendant les fonctionnalités des serveurs secondaires à l’aide du traitement des déclencheurs et de la prise en charge des actions au niveau utilisateur dans l’interface utilisateur.

Traitement des déclencheurs

Les professionnels qui travaillent avec de grandes installations ont des centaines, voire des milliers de déclencheurs qui se lancent lors de changements dans le VCS, de mises à jour de paquets et de nouveaux artefacts. Pour les aider à atteindre les performances les plus élevées possibles, nous permettons désormais aux serveurs secondaires de participer à ce processus pour de décharger le serveur principal.

Actions au niveau de l'utilisateur

Nous avons amélioré l'interface utilisateur du serveur secondaire, ce qui permet de modifier les profils utilisateur, de changer la vue des projets et des configurations, de gérer les agents de build, etc.

Déploiement plus facile des agents de build dans le cloud

TeamCity 2020.1 est livré avec une nouvelle option pour télécharger une distribution d'agent pré-packagé depuis le serveur TeamCity. Les agents de build pré-packagés n'ont pas besoin de se mettre à jour lors de la connexion au serveur TeamCity, ce qui rend la création et la mise à jour d'images cloud plus rapides et plus simples.

Passez vos notifications au niveau supérieur

Passez vos notifications au niveau supérieur

Pour porter les capacités de notification de TeamCity vers de nouveaux sommets, nous avons mis en œuvre une nouvelle fonctionnalité de build qui permet aux administrateurs de projet de configurer des alertes automatiques pour toute l’équipe. De nouvelles notifications peuvent être configurées dans la configuration de la build, vous pouvez donc les modifier, les réutiliser et les partager à l’aide de la DSL Kotlin.

Le tout nouvel outil de notifications Slack permet à votre équipe de recevoir des notifications sur l’état de vos builds directement dans Slack.

Le pouvoir des intégrations

Jira Software Cloud

Jira Software Cloud

TeamCity a toujours bénéficié d’une intégration élégante avec Jira, qui remplace automatiquement les codes de tickets dans les messages de commit par des liens vers les tickets Jira respectifs. Pour prendre en charge un plus grand nombre de workflows encore, nous avons étendu l’intégration et commencé à envoyer l’état de vos builds et déploiements à Jira Software Cloud. Vous pouvez maintenant consulter vos pipelines CI/CD et l’historique des versions directement dans votre outil de suivi des tickets, et consulter les tickets associés aux builds en échec.

Azure DevOps

Azure DevOps

Nous avons étendu la liste des services d’hébergement Git pris en charge avec la fonctionnalité de build Pull Requests, et ajouté la prise en charge des requêtes pull Azure DevOps. La nouvelle option vous permet d’exécuter automatiquement des builds sur des branches de requête pull d’Azure DevOps, de la même manière que ce que permettent GitHub et GitLab.

Nouvelle interface utilisateur Sakura

Nouvelle interface utilisateur Sakura

La plupart des développeurs utilisent les CI/CD tous les jours et nous souhaitons qu’ils s’y sentent comme chez eux. C’est pourquoi nous poursuivons notre quête pour créer une nouvelle interface utilisateur qui sera rapide et facile à utiliser, et nous permettra de proposer de nouvelles fonctionnalités plus rapidement.

Pour prendre en charge davantage de cas d’utilisation du TeamCity classique, l’interface utilisateur expérimentale de la version 2020.1 intègre des pages Agents et Projects actualisées et permet de configurer la barre latérale du projet.

Mais l'intérêt de cette nouvelle version ne s'arrête pas là ! Pour consulter la liste complète des changements de TeamCity 2020.1, veuillez vous reporter à la documentation TeamCity.

Nouveautés de TeamCity 2019.2

TeamCity 2019.2 vous offre d'excellents moyens de gérer le nettoyage de vos builds et de suivre les performances de votre serveur. Il prend en charge les modèles de lancement EC2 et propose une nouvelle syntaxe DSL pour définir les chaînes de build. Il fournit en outre un moyen simple d'exécuter des builds personnelles avec des correctifs Git, et apporte nombre d'améliorations à l'interface utilisateur expérimentale.

Le nouvel âge du nettoyage

Règles de nettoyage dans TeamCity

TeamCity 2019.2 apporte de nouvelles dimensions de contrôle sur les artefacts et les données historiques créés par vos builds. Le remaniement du moteur de nettoyage vous permet de configurer plusieurs stratégies avec un large éventail de filtres. Vous pouvez par exemple choisir de conserver toutes les builds de certaines branches, ou celles qui comportent des étiquettes spécifiques.

L'utilité de nouvelles règles de nettoyage nous semble particulièrement notable pour les entreprises qui mènent de nombreux projets, et pour les équipes qui utilisent des branches de fonctionnalités au cours du développement.

Vue globale de votre CI

Mesures de TeamCity dans Prometheus

Les pros adorent les outils qui les aident à surveiller le comportement et les performances des systèmes critiques à leur mission. À compter de la version 2019.2, TeamCity expose ses mesures au moyen d'un terminal HTTP, ce qui permet de les collecter avec Prometheus pour les visualiser dans son interface Web, ou dans un tableau de bord Grafana.

Ces mesures comprennent les informations de performance du serveur ainsi que divers détails sur les agents, les projets et les configurations de build.

L'évolutivité, passée au niveau supérieur

Pour beaucoup de grands groupes, une CI haute performance est essentielle aux workflows. TeamCity fait un pas de plus vers une configuration à plusieurs nœuds. Il vous permet d'ajouter des builds à la file d'attente, de gérer les problèmes de builds et les investigations, et d'effectuer d'autres actions de niveau utilisateur – sur un serveur secondaire.

Plus de moyens d'être productifs avec l'interface expérimentale

Nouvelle page de build dans l'interface utilisateur expérimentale

Les développeurs ouvrent souvent TeamCity plusieurs fois par jour. C'est pourquoi nous souhaitons qu'ils puissent y trouver rapidement ce qu'ils cherchent, quelles que soient la taille et la complexité de leurs projets. Conformément à la feuille de route de l'interface utilisateur de TeamCity, nous vous présentons une nouvelle page de build qui vous permet de naviguer simplement dans l'historique des builds, d'enquêter sur les problèmes et de découvrir des erreurs de configuration ou des goulots d'étranglement dans vos chaînes de builds.

Découvrez l'interface utilisateur expérimentale, dont nous sommes particulièrement fiers.

Modèles de lancement EC2. Des builds à des niveaux inespérés

Prise en charge des modèles de lancement EC2

Nous voulons faire en sorte que TeamCity comporte tout ce dont vous avez besoin dans un workflow moderne. La version 2019.2 ajoute la prise en charge des modèles de lancement EC2 et permet d'exécuter des agents de build cloud en utilisant les paramètres de lancement de votre compte AWS. Grâce aux modèles de lancement, la mise à jour et l'installation de nouveaux logiciels sur les agents de build devient simple et direct. Vous n'avez plus besoin d'opérer le moindre changement dans la configuration de votre projet TeamCity.

Boostez votre DSL

Des chaînes de builds faciles à construire

Adieu les clics, bonjour les scripts. Le DSL de Kotlin propose désormais une syntaxe simple et très directe pour définir les chaînes de build. Configurez des builds parallèles et séquentiels, ainsi que des conditions d'échec et des dépendances, et stockez l'ensemble sous forme de code.

De nombreux paramètres. Un seul modèle.

La configuration de projet s'est grandement simplifiée. À compter de la version 2019.2, vos configurations de DSL Kotlin peuvent inclure des paramètres personnalisés que vous devez définir dans l'interface utilisateur lors de l'importation du projet.

Exécutez davantage. Attendez moins. Commencez des builds à l'aide de correctifs Git.

Testez rapidement vos modifications : créez un correctif Git, mettez-le en ligne sur TeamCity puis exécutez une build personnelle, sans créer de branche ni de commit.

Pour consulter la liste complète des changements de la version 2019.2, reportez-vous à la documentation de TeamCity.

Nouveautés de TeamCity 2019.1

Nouvelle présentation, plus de convivialité, toujours moins de clics

Nouvelle interface utilisateur Barre latérale Aperçu du projet

L'interface de TeamCity a été totalement remaniée et voici un avant-goût de ce que vous allez obtenir dans cette version.

Non seulement nous avons amélioré la présentation, mais nous avons également mis à jour la pile technologique sous-jacente, de telle sorte que l'interface fonctionne désormais comme une application à page unique. Cela signifie que vous pouvez accéder plus rapidement à ses éléments et que toutes les modifications apparaissent instantanément. Découvrez la feuille de route de l'interface de TeamCity pour vous tenir informé de toutes les modifications prévues.

Dans la version 2019.1, nous avons ciblé les pages de travail sur les projets et les configurations de build.

Aperçu du projet

Le nouvel aperçu du projet vous propose une vue de type tableau de bord sur vos configurations de builds. Chaque configuration reçoit sa propre carte qui affiche un histogramme contenant jusqu'à 14 des derniers builds. Pour chacun des builds, vous pouvez voir son état (vert traduit la réussite, rouge l'échec), le temps de build et la durée passée par le build dans la file d'attente. Vous y trouverez également des informations sur le build en cours d'exécution.

L'onglet Branches

L'onglet Branches

L'onglet Branches remanié affiche celle par défaut en haut, et masque le reste dans un bloc extensible situé en dessous. Les détails des derniers builds de la branche par défaut sont maintenant immédiatement visibles, ce qui améliore la visibilité des données importantes.

Prise en charge totale de GitLab dès la première minute

Intégration complète de GitLab
GitLab

Vous utilisez GitLab ? TeamCity 2019.1 prend entièrement en charge GitLab. Vous pouvez maintenant configurer une connexion GitLab et créer des projets dans TeamCity en un clic, simplement en sélectionnant un projet GitLab dans la liste.

Nous avons également inclus la prise en charge des requêtes de fusion de GitLab, ce qui permet de configurer TeamCity pour exécuter automatiquement le build sur chaque demande de fusion, puis de procéder à une fusion automatique si le processus de build aboutit.

Go jusqu'au bout

Prise en charge native de Go
GoLand

TeamCity prend maintenant le langage Go en charge en natif. Ajoutez vos projets Go et TeamCity en détecte les tests et génère des rapports automatiques permettant de bénéficier d'informations importantes concernant le statut du test, son historique dans les différents builds et sa durée, et enfin de marquer les tests instables comme fragiles. Grâce à l'onglet Test History, vous pouvez maintenant approfondir vos tests Go.

Authentification basée sur les jetons

Authentification basée sur les jetons

En complément de l'authentification HTTP de base, TeamCity prend désormais en charge l'authentification basée sur les jetons d'accès permanents. Les jetons sont utiles pour l’authentification de l’API REST. Ils vous évitent d’exposer un nom d’utilisateur et un mot de passe dans les scripts.

Dépendances des instantanés sans source de synchronisation

Dépendances des instantanés sans source de synchronisation

Vous pouvez maintenant désactiver la synchronisation des révisions de code pour les dépendances d'instantanés. Cela est pratique lors des déploiements et permet de promouvoir l'une des builds les plus anciennes de la chaîne au moyen de la configuration de déploiement.

Requêtes AWS Spot Fleet

Traitement du cycle de vie du build

Grâce à cette solution plus flexible de création d'instances Spot, vous disposez d'un contrôle plus fin de votre code Spot Fleet. TeamCity 2019.1 permet d'envoyer et de modifier le fichier de configuration Spot Fleet et de spécifier la stratégie, de définir la capacité de la cible et d'ajouter des balises à vos instances. Il s'agit d'une solution plus avancée et économique d'exécuter vos builds sur AWS.

Traitement du cycle de vie des builds sur un nœud secondaire

Le nœud secondaire dispose désormais d'une responsabilité supplémentaire : traiter le cycle de vie de la build. Si vous l'activez, le nœud secondaire traite les tâches se rapportant à la build, telles que son exécution ou finition, le chargement d'artefacts et le traitement des conditions d'échec. Cette modification étend la liste déjà considérable des tâches que vous pouvez déplacer de votre serveur principal vers un serveur secondaire, à savoir la collecte de modifications, l'utilisation du serveur en tant que nœud de sauvegarde en lecture seule et, désormais, le traitement du cycle de vie du build.

Traitement du cycle de vie du build

Chargement à la demande des outils

Les outils ne seront chargés sur les agents que sur demande. Les outils nécessaires ne sont chargés que lorsque le premier build qui en a besoin apparaît. Cela améliore de façon significative les durées de mise à niveau de l'agent du build et évite de surcharger le trafic réseau.

Mais l'intérêt de cette nouvelle version ne s'arrête pas là ! Découvrez les autres nouvelles fonctionnalités.