Feuille de route de TeamCity

Cette page répertorie les nouvelles fonctionnalités que nous développons ou concevons activement pour TeamCity. Elle devrait vous donner un aperçu des annonces auxquelles vous pouvez vous attendre au cours de l'année qui vient.

Les informations sur cette page sont mises à jour régulièrement. État actuel des fonctionnalités de la feuille de route :

9
développement
5
conception
2
prospection
3
Disponible en version EAP
TeamCity Cloud

TeamCity Cloud

Pour permettre aux développeurs de créer d'excellents logiciels sans avoir à installer et à maintenir une infrastructure de build, nous travaillons sur TeamCity Cloud - une solution CI/CD totalement gérée qui sera entièrement hébergée et supervisée par JetBrains.

Pour en savoir plus

Évolutivité multi-serveur

Évolutivité 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 améliorons le fonctionnement de TeamCity dans un environnement de clustering en étendant les capacités des serveurs secondaires.

Pour en savoir plus

Principales améliorations de l'intégration continue

Principales améliorations de l'intégration continue

Pour vous donner un meilleur contrôle sur votre CI, nous travaillons sur une variété de nouvelles fonctionnalités qui faciliteront l'automatisation de vos pipelines DevOps et vous aideront également à organiser votre processus de développement de manière plus efficace.

Pour en savoir plus

DSL Kotlin

Configuration par le code

Nous sommes heureux que de plus en plus d'utilisateurs se mettent à stocker leurs configurations CI/CD sous forme de code. Dans un proche avenir, nous allons rendre le DSL Kotlin encore plus expressif et ajouter d'autres moyens de s'y initier.

Pour en savoir plus

Outils d'exécution de builds et intégrations

Outils d'exécution de builds et intégrations

Les développeurs du monde entier adorent les intégrations étroites de TeamCity avec les outils de builds et les services externes, et nous prenons grand soin d'optimiser leur prise en charge. Dans cette section, vous découvrirez les nouvelles intégrations que nous prévoyons d'ajouter.

Pour en savoir plus

Fonctionnalités cloud

Fonctionnalités cloud

Nous voulons faire en sorte que TeamCity comporte tout ce dont vous avez besoin dans un workflow moderne. C'est pourquoi nous travaillons sur une gamme de fonctionnalités qui vous permettront de configurer et d'exécuter plus facilement vos builds dans le cloud.

Pour en savoir plus

Nouvelle interface utilisateur « Sakura »

Nouvelle interface utilisateur « Sakura »

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. Notre objectif actuel est de faire en sorte que l'interface utilisateur Sakura prenne en charge tous les principaux cas d'utilisation de l'interface utilisateur classique.

Pour en savoir plus

TeamCity Cloud

Développement

Les développeurs doivent avoir le pouvoir de créer de bons logiciels sans avoir à gérer les problèmes de l'installation et de la maintenance de l'infrastructure de build. C'est pourquoi nous travaillons sur TeamCity Cloud, une solution CI/CD entièrement gérée qui sera entièrement hébergée et supervisée par JetBrains. Cette version contiendra tout ce que vous aimez du TeamCity original et exécutera vos builds et vos tests sur des instances dédiées dans le cloud, totalement isolées des autres utilisateurs. Pour les utilisateurs actuels, nous fournirons un moyen de migrer les installations locales vers la solution cloud.

TeamCity Cloud est actuellement en version bêta publique et nous prévoyons sa publication officielle avant la fin de 2020.

Inscrivez-vous pour la version bêta

Évolutivité 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 améliorons le fonctionnement de TeamCity dans un environnement de clustering en étendant les capacités des serveurs secondaires par de nouvelles fonctionnalités.

Interface utilisateur complète

Développement
Pour un meilleur contrôle de votre intégration continue, l'interface utilisateur limitée actuelle du serveur secondaire sera remplacée par une version complète. Elle permettra de modifier des configurations de builds, de gérer des agents cloud et d'effectuer d'autres actions qui n'étaient pas disponibles auparavant. Votre équipe pourra donc continuer à travailler avec TeamCity pendant que le serveur principal est en maintenance.

Traitement de la file d'attente des builds

Conception
Notre objectif global est de rendre le serveur secondaire égal au serveur principal à tous égards. Le prochain arrêt sur la feuille de route permettra au serveur secondaire de traiter la file d'attente des builds et de lancer des builds.

Principales améliorations de l'intégration continue

Paramètres définis par déclencheur

Développement

Parmi les autres demandes de fonctionnalité populaires, nous allons également implémenter les paramètres définis par déclencheur. Cette fonction vous donnera un meilleur contrôle sur vos builds et vos tests, et vous permettra de les exécuter différemment en fonction de ce qui les a déclenchés. Un cas d'utilisation type de cette fonctionnalité pourrait être la publication automatique d'une build nocturne lorsqu'elle est déclenchée par une planification (mais pas par d'autres déclencheurs).

Division intelligente des tests

Conception

Plus vous avez de tests, plus leur exécution prend du temps. Souvent, vous remarquez que bon nombre de vos agents de build ne font rien d'autre qu'attendre qu'un agent donné termine ses tests. Pour gérer cette situation, nous travaillons sur une nouvelle fonctionnalité qui divisera intelligemment les tests en plusieurs groupes de tests aux durées similaires, puis les exécutera sur plusieurs agents de build en parallèle. Cela vous donnera les résultats de vos tests plus vite, vous pourrez donc avancer plus et attendre moins.

Builds sans agent

Développement

Les agents de build TeamCity combinent des capacités et une polyvalence sans rivales chez les autres CI. Mais lorsqu'ils utilisent des outils externes, toute cette puissance reste inutilisée car ils doivent attendre la fin d'une tâche externe. Pour optimiser le fonctionnement de TeamCity dans ces situations, nous souhaitons implémenter une nouvelle API « de build sans agent » qui permettra d'utiliser des outils externes sans dépendre des agents de build TeamCity. Toutes les tâches effectuées via cette API s'afficheront comme des builds normales dans TeamCity, avec leurs propres rapports, état et historique.

Si vous souhaitez un exemple de cas où cette fonctionnalité pourrait être très utile, prenez l'utilisation d'un service de déploiement externe. Imaginez que vous utilisez un service de déploiement avec une étape d'approbation manuelle dans un pipeline de versions. Si vous l'appelez depuis un agent TeamCity, vous pourriez passer des heures, voire des jours, à attendre que quelqu'un approuve la publication. Si elle ne nécessitait pas d'agent de build, votre configuration CI serait tellement plus efficace ! La nouvelle API vous aidera à éviter ce genre de situations.

Faites entendre votre voix ! Veuillez décrire vos propres cas d'utilisation dans lesquels vous souhaiteriez utiliser les builds sans agent décrites ci-dessus dans le ticket YouTrack correspondant.

Interprétation de tests instables dans une build

Disponible en version EAP

L'échec de tests n'implique pas forcément que le code est cassé. Souvent, si votre test réussit au moins une fois sur plusieurs exécutions, cela signifie que le code fonctionne correctement. Par exemple, votre test d'interface utilisateur peut échouer en raison d'un problème de réseau, mais réussir à la deuxième tentative, et vous souhaiterez peut-être qu'il soit signalé comme réussi pour indiquer l'absence de problèmes de rendu.

TeamCity a toujours eu une politique stricte concernant les tests en échec : tout échec de test entraînait un échec de l'étape de la build. Mais ce n'était pas pratique dans certains scénarios de test. Pour prendre en charge davantage de workflows, nous vous permettrons de choisir comment gérer ces situations, afin que vous puissiez garder votre build en vert même si certains tests semblent instables dans cette même build.

Configuration par le code

Grâce à l'expressivité du DSL Kotlin, nos utilisateurs se lancent vraiment dans le stockage de leurs configurations CI/CD sous forme de code. Nous continuons à l'améliorer et voici les principaux changements que nous planifions dans un proche avenir.

Affichage de la configuration du projet en tant que DSL

Développement

Le bouton View DSL fournit un excellent moyen d'apprendre à décrire votre configuration de build en Kotlin. Pour le moment, il n'est disponible que pour les configurations de build, ce qui n'est pas très utile si vous souhaitez écrire des configurations pour des projets complets ou si vous cherchez le bon morceau de code pour configurer un élément précis. Nous allons ajouter des boutons similaires à d'autres sections de TeamCity, afin que vous puissiez toujours trouver la bonne façon de configurer vos racines VCS, vos paramètres de nettoyage ou vos projets entiers - sous forme de code Kotlin.

Omission des importations dans le code DSL

Conception

Nous voulons que le DSL Kotlin soit aussi synthétique et expressif que possible. Pour faciliter la description de vos configurations de build dans Kotlin, nous vous autoriserons à omettre la section des importations au début du fichier settings.kts. Cela signifie que settings.kts peut démarrer directement avec la section {...} du projet et ne vous obligera pas à spécifier explicitement les importations requises pour compiler le script.

Désactivation des modifications via l'interface utilisateur

Développement

TeamCity vous permet de configurer des pipelines CI/CD de différentes manières en fonction de votre workflow préféré. Vos projets peuvent être configurés via le DSL, via l'interface utilisateur ou via un mélange des deux. Toutefois, mélanger des modifications manuelles et des modifications DSL peut entraîner beaucoup de confusion et de problèmes de version. Pour préserver la prévisibilité et la facilité de gestion de vos configurations, nous ajouterons une nouvelle option qui permettra aux administrateurs d'interdire la modification des configurations de projet via l'interface utilisateur si elles sont configurées à l'aide du DSL Kotlin.

Outils d'exécution de builds et intégrations

Les développeurs du monde entier adorent les intégrations étroites de TeamCity avec les outils de builds et les services externes, et nous prenons grand soin d'optimiser leur prise en charge. Vous trouverez ci-dessous une liste des nouvelles fonctionnalités que nous prévoyons d'ajouter.

.NET 5

.NET 5

Développement

Beaucoup de nos utilisateurs sont enthousiasmés par les projets de Microsoft concernant .NET 5, une nouvelle plateforme qui unira .NET Core et .NET Framework. .NET 5 éliminera les différences entre le développement pour différentes plateformes, et nous prévoyons de suivre le même chemin dans TeamCity. Le tout nouvel outil d'exécution de build .NET réunira les 5 outils actuels et vous permettra de créer tout type d'application, avec toutes les options d'exécution disponibles.

Nous ne prévoyons pas de supprimer les anciens outils d'exécution de build dans les prochaines versions, mais notre objectif global est de n'implémenter les nouvelles fonctionnalités et les corrections de bogues que dans le nouvel outil.

Python

Python

Développement

Au cours des dernières années, Python a connu une énorme croissance et nous avons également constaté un grand intérêt pour les solutions CI/CD pour Python. Nous prévoyons d'implémenter un nouvel outil d'exécution Python qui prendra en charge la plupart des frameworks de développement et de test populaires pour Python et vous offrira une expérience cohérente dans toutes les facettes de votre workflow d'intégration continue.

Nous avons déjà une idée générale de ce qu'une intégration Python doit inclure, mais nous vous invitons à apporter vos propres suggestions dans le ticket YouTrack correspondant.

JetBrains Space

JetBrains Space

Disponible en version EAP
Conception

Notre société a récemment lancé un nouveau produit, Space, un environnement d'équipe intégré qui comprend un ensemble complet d'outils pour le développement de logiciels moderne. Space offre tant d'opportunités d'intégration avec TeamCity :

  • Création de requêtes d'extraction et publication des états des builds
  • Envoi de notifications aux tchats et génération d'éléments sur les listes de tâches
  • Synchronisation avec un répertoire d'équipe et héritage des autorisations du projet depuis Space
  • Et bien plus encore

Nous travaillons en étroite collaboration avec l'équipe Space pour trouver les moyens les plus utiles d'intégrer les deux produits, et nous prévoyons de commencer à déployer certaines de ces intégrations cette année.

Bitbucket Cloud

Bitbucket Cloud

Prospection

Nous explorons des moyens d'ajouter la prise en charge des requêtes d'extraction Bitbucket Cloud. Pour le moment, nous ne savons pas très bien dans quelle mesure il est possible d'intégrer Bitbucket Cloud, notre plan est donc le suivant :

  1. Implémenter la prise en charge des requêtes d'extraction effectuées dans un référentiel spécifique (pas de forks).
  2. Recueillir les commentaires pour savoir si l'implémentation initiale répond aux besoins de nos utilisateurs et étudier d'autres scénarios si ce n'est pas le cas.

Vous pouvez voter pour ce problème dans le ticket YouTrack correspondant.

Fonctionnalités cloud

Caches persistants pour les agents cloud

Conception

Les équipes utilisant TeamCity dans le cloud doivent avoir la possibilité de terminer leurs builds aussi rapidement que si elles utilisaient des installations locales. Les caches cloud persistants permettront aux agents de build dans le cloud d'échanger rapidement du code source, des artefacts de build et divers paquets entre eux, ce qui fera gagner beaucoup de temps et économiser sur les coûts du réseau.

(Moins de téléchargements, c'est bon pour la planète : cela économise de l'électricité et réduit votre empreinte carbone. Cette fonctionnalité vous permet donc d'améliorer votre impact sur l'environnement alors même que vos builds accélèrent.)

Nouvelles options de licences

Prospection

De plus en plus de nos clients sont disposés à exécuter des agents de build dans le cloud, car cela leur permet d'augmenter rapidement la capacité de leurs pipelines de livraison en cas de besoin. Cependant, la politique de licence actuelle de TeamCity est restrictive pour eux car elle requiert des licences annuelles pour des agents de build qu'ils n'utilisent que pendant les heures de pointe. Pour remédier à cela, nous allons repenser notre approche des licences TeamCity dans les installations cloud.

Bien que nous n'ayons pas encore trouvé de solution, nous pensons qu'il est important d'annoncer que nous travaillons en ce sens. Si vous avez un cas d'utilisation pertinent, n'hésitez pas à le partager dans le ticket YouTrack correspondant.

Nouvelle interface utilisateur « Sakura »

Disponible en version EAP
Développement

Les CI/CD constituent l'un des outils que la plupart des développeurs utilisent chaque jour, et nous souhaitons qu’ils s’y sentent comme chez eux. L'année dernière, nous avons inauguré une nouvelle interface utilisateur expérimentale (nom de code « Sakura »), et elle a vraiment fait ses preuves. Elle est rapide, puissante et moderne, et nous sommes fiers de ses résultats après si peu de temps. Les prochaines améliorations de l'interface utilisateur Sakura porteront sur les points suivants :

  • Page de file d'attente de builds
  • En-tête
  • Pages d'investigation et muettes

De nombreux utilisateurs nous ont demandé si nous prévoyions de supprimer l'ancienne interface utilisateur.

La réponse est non. L'interface utilisateur Sakura ne remplacera pas l'interface utilisateur classique de sitôt. Au cours de l'année qui vient, nous prévoyons de nous concentrer sur l'amélioration de ce qui a déjà été implémenté dans l'interface utilisateur Sakura jusqu'à obtenir la parité des fonctionnalités et prendre en charge tous les principaux cas d'utilisation de l'interface utilisateur classique. Cela nous permettra d'en faire l'interface par défaut, mais même dans ce cas, nous conserverons la possibilité d'utiliser l'interface utilisateur classique.

Nous sommes chanceux de pouvoir tester chaque petit changement de l'interface utilisateur dans JetBrains. Les builds nocturnes de TeamCity sont utilisés par des dizaines d'équipes avec des pratiques de CI/CD très différentes, allant des développeurs individuels à d'énormes projets comme IntelliJ IDEA et Kotlin. L'interface utilisateur classique n'a pas bénéficié de cette opportunité : elle s'est développée naturellement avec l'entreprise et a été construite à l'aide de technologies qui ont maintenant plus de 10 ans. Elle a depuis longtemps atteint ses limites, et nous pensons qu'elle ralentit désormais le développement de nouvelles fonctionnalités. C'est pourquoi nous construisons l'interface utilisateur Sakura. Nous sommes convaincus qu'elle apportera un nouvel avenir merveilleux à TeamCity et à tous nos utilisateurs.