Fonctionnalités cloud
Avec TeamCity, nous voulons vous offrir tout ce dont vous avez besoin pour des pipelines CI/CD rapides et rentables. C'est pourquoi nous travaillons sur une série de fonctionnalités qui vous permettront de configurer et d'exécuter plus facilement vos builds dans le cloud.
Caches persistants pour les agents cloud
Les équipes utilisant TeamCity dans le cloud doivent pouvoir terminer leurs builds aussi rapidement que si elles utilisaient des installations locales. Des caches cloud persistants permettront aux agents de build dans le cloud de transférer des dépendances de build (telles que les artefacts Maven et les paquets NPM) les uns aux autres. Vous gagnerez ainsi du temps et réduirez les coûts de réseau.
Réduire le nombre de téléchargements est en outre positif pour la planète. Cela économise de l'électricité et réduit votre empreinte carbone. Cette fonctionnalité vous aidera à améliorer votre impact sur l'environnement alors même que vos builds accélèrent.
Réorganisation de la gestion des identifiants AWS
Nous avons récemment publié un nouveau système de gestion des identifiants (AWS Connection) qui fournit aux fonctionnalités de build et aux intégrations cloud de TeamCity des identifiants de sécurité AWS temporaires, ne disposant que des droits nécessaires pour effectuer une tâche spécifique. Notre prochaine étape consiste à implémenter la prise en charge de AWS Connection pour tous les plugins disponibles dans TeamCity. Votre équipe n'aura plus à se soucier de configurer manuellement l'accès aux ressources EC2, ECR, S3 et autres.
Prise en charge automatique de Microsoft Azure
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. Pour soutenir les utilisateurs qui migrent vers Microsoft Azure, nous prévoyons d'améliorer et d'intégrer le plugin TeamCity Azure.
Constructeur d'images d'agents de build
Grâce au constructeur d'images de TeamCity, vous pourrez créer des images VM personnalisées des agents de build TeamCity pour divers environnements. Cela vous permettra d'accélérer vos builds en utilisant des dépôts VCS préétablis, des dépendances de build, des images Docker, etc.
Mode Exécuteur
Nous souhaitons prendre en charge un planificateur standard, tel que Kubernetes, HashiCorp Nomad, AWS ECS ou autre pour exécuter des tâches de build simples sans avoir à spécifier et gérer un agent de build.
Cela vous permettrait de commencer les configurations de build de projet sans avoir à vous préoccuper des workers exécutant vos builds.
Une telle approche serait pertinente pour les petites tâches simples qui ne nécessitent pas de caches locaux pour les données racine du système de contrôle de version, les dépendances, etc. Cela augmente également l'utilisation des ressources au moyen de planificateurs. Les planificateurs peuvent exécuter directement plusieurs tâches en parallèle sur le même nœud de cluster.
Agents hébergés par JetBrains
Nous envisageons d'ajouter des options pour les agents hébergés par JetBrains pour TeamCity Cloud. Cela inclura l'ajout d'agents macOS facturés à la minute et la mise à disposition d'agents Linux basés sur ARM.
TeamCity multi-locataires
Actuellement, TeamCity Cloud fournit un serveur différent pour chaque client. Nous explorons la possibilité d'héberger plusieurs projets sur le même serveur. Cela nous aidera à réduire les coûts, voire à fournir une version gratuite de TeamCity Cloud.
Outils d'exécution de builds et intégrations
Les développeurs du monde entier adorent les intégrations poussées de TeamCity avec les outils de builds et les services externes, et nous nous efforçons d'optimiser leur prise en charge. Vous trouverez ci-dessous une liste des nouvelles fonctionnalités d'intégration que nous prévoyons d'ajouter.
Une fonctionnalité de build Pull Requests pour contrôler le déclenchement
Actuellement, la fonctionnalité de build Pull Requests étend les spécifications des branches d'une racine VCS afin d'inclure les branches des requêtes d'extraction ouvertes qui correspondent à certains critères de filtrage.
Nous voulons étendre cette fonctionnalité afin que vous puissiez déclencher automatiquement des builds pour un sous-ensemble de requêtes d'extraction, sans pour autant vous empêcher de déclencher des builds pour d'autres branches manuellement.
Consolidation des fonctionnalités de projet et de build liées aux intégrations
Cette fonctionnalité vous permettra de configurer une connexion (par exemple, à GitHub) au niveau du projet. Vous pourrez indiquer directement dans les paramètres de connexion si vous souhaitez que TeamCity centralise les requêtes d'extraction et les informations de suivi des tickets, mais aussi quelles configurations de builds doivent publier leur état.
Cette fonctionnalité vous fera gagner beaucoup de temps, car vous pourrez configurer les paramètres au niveau du projet en une seule fois.
Interface utilisateur pour la gestion des jetons
Les jetons OAuth émis via Connections sont conservés dans un stockage de jetons interne de TeamCity. Ils sont actuellement extraits du stockage lorsque certains paramètres (par exemple, une racine VCS ou une fonctionnalité de build) sont configurés via l’interface d’administration.
Nous voulons introduire une interface utilisateur pour la gestion des jetons. Elle vous permettra de contrôler l'utilisation de vos jetons et leurs portées, en plus de :
- Consulter les identifiants et les connexions des jetons, les comptes utilisés pour émettre le jeton, etc.
- Émettre de nouveaux jetons afin qu'ils puissent être référencés par identifiant (par exemple, à partir du code DSL).
- Supprimer des jetons du stockage.
- Consulter et modifier les portées des jetons dans le projet.
- Visualiser l'utilisation réelle des jetons à partir de divers paramètres.
Configuration automatisée de nouveaux projets à partir du VCS
Les grandes entreprises apprécient la capacité de TeamCity à évoluer jusqu'à gérer des milliers d'agents de build et des dizaines de milliers de projets. Toutefois, à un moment donné, la création de nouveaux projets peut devenir une réelle contrainte, qui se répète par ailleurs à chaque fois.
Avec cette fonctionnalité, nous étudions la possibilité de créer automatiquement un projet dans TeamCity lorsque le nouveau dépôt .teamcity est créé.
Prise en charge des requêtes Pull dans l'interface utilisateur
TeamCity offre maintenant une prise en charge dédiée des requêtes Pull de GitHub. Du point de vue de TeamCity, les requêtes Pull constituent une branche spéciale. Nous allons marquer ces branches dans l'interface utilisateur de façon à les rendre facilement reconnaissables.
Implémentation de la prise en charge de GitHub Checks
La prise en charge de GitHub Checks nous permet de générer des rapports plus complets sur ce qui s'est passé au cours du processus de build, en fonction des données provenant de GitHub.
Principaux avantages de cette fonctionnalité :
- Rapports hypertexte étendus au lieu de simples statuts.
- Possibilité d'annotation d'emplacements spécifiques dans le code source (p. ex., pour les inspections).
Critères de filtre supplémentaires pour la fonctionnalité de création de requêtes Pull
Actuellement, il n'y a qu'un seul filtre de branche cible dans la fonctionnalité de création de requêtes Pull de TeamCity. Nous envisageons d'ajouter de nouveaux filtres, notamment pour les statuts de révision, les étiquettes, les rôles de l'auteur, etc.
Pour le développement de jeux
TeamCity combine des capacités et une polyvalence sans rivales chez les autres outils de CI. Il n'est donc pas étonnant qu'il figure parmi les solutions de CI les plus souvent utilisées dans le développement de jeux. Nous commençons à explorer les contributions qu'elle peut apporter à cette industrie dans trois domaines principaux :
- La prise en charge d'Unity
- Prise en charge d'Unreal Engine.
- Les workflows CI/CD généraux dans le développement de jeux
Vous souhaitez utiliser TeamCity pour créer vos jeux ? Nous vous invitons à vous inscrire ici pour participer à nos recherches.
Amélioration de l'intégration de Perforce
TeamCity propose une intégration native avec Perforce Helix Core, l'un des systèmes de contrôle de version les plus utilisés dans le développement de jeux. Voici ce que nous avons prévu pour la prise en charge de Perforce.
Suppression automatique des espaces de travail Perforce créés par TeamCity
L'utilisation de la vérification côté agent de Perforce crée des espaces de travail Perforce. Lorsqu'un agent TeamCity n'est plus utilisé, les espaces de travail restent sur le serveur Perforce.
Pour éviter de gaspiller les ressources du serveur, nous allons introduire la suppression automatique des espaces de travail Perforce créés par TeamCity pour les agents TeamCity qui ne sont plus actifs.
Davantage de contrôle sur les commentaires de révision Helix Swarm à partir de l'éditeur d'état des commits
L'éditeur d'état des commits fournit actuellement des informations sur toutes les étapes du build (en attente, commencé, réussite/échec, etc.), ce qui peut prendre des proportions considérables.
Nous allons vous donner davantage de contrôle sur les commentaires qui sont envoyés et sur les états qui les déclenchent.
Personnalisation du nom de l'espace de travail Perforce pour la vérification côté agent
Actuellement, TeamCity génère automatiquement le nom de l'espace de travail Perforce lors de la vérification côté agent. Nous prévoyons d'ajouter une option permettant d'indiquer un schéma personnalisé pour le nom de l'espace de travail. Ce schéma permettra d'utiliser :
- L'identifiant du projet et l'identifiant de la configuration.
- L'identifiant externe de la racine VCS.
- Nom du répertoire de checkout.
Prise en charge d'Unreal Engine
Unreal Engine est l'un des moteurs les plus populaires pour le développement de jeux. Nous travaillons sur un nouveau plugin Unreal Engine qui offrira les fonctionnalités suivantes aux utilisateurs de TeamCity :
- Détection des installations d'Unreal Engine sur les agents de build.
- Exécuteur dédié pour Unreal Engine.
- Découverte automatique des étapes de build d'Unreal Engine.
- Journaux de build structurés avec mise en évidence des problèmes.
- Rapports de test.
Configuration multinœuds
Exécuter plusieurs nœuds 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 clusters, en implémentant de nouvelles fonctionnalités pour les configurations à plusieurs nœuds.
Amélioration de la disponibilité
La maintenance du serveur ne doit pas empêcher les développeurs d'exécuter leurs builds. Nous prévoyons d'investir davantage dans les fonctionnalités qui améliorent la disponibilité de TeamCity (notamment la conversion automatique des nœuds secondaires en nœuds principaux), et nous continuerons à supprimer la dépendance au répertoire de données partagé dans une configuration multinœuds.
Amélioration de la propagation des modifications dans les fichiers de configuration
Nous envisageons de commencer à stocker tous les fichiers de configuration dans un dépôt Git local. Vous pourrez utiliser ce référentiel pour partager les fichiers de configuration entre plusieurs nœuds TeamCity dans une configuration multinœuds.
Cela nous permettra de mettre en place des notifications de transaction pour toute modification de ces fichiers, et d'assurer l'atomicité de ces modifications ainsi que celle des notifications du nœud secondaire les concernant.
Service de journal de build autonome
Dans la configuration multinœuds, tous les nœuds fonctionnent avec des fichiers de journaux de build dans un répertoire de données partagé. La plupart du temps, un nœud « possède » le fichier journal correspondant à un build. Ce nœud écrit dans le fichier, tandis que les autres nœuds ne peuvent que le lire.
Si un nœud TeamCity décide que le nœud qui « possède » le fichier journal a subi un crash (alors qu'il fonctionne parfaitement), un autre nœud peut commencer à écrire dans le même fichier journal et le corrompre.
Nous envisageons d'implémenter un service de journal de build autonome qui est accessible depuis tous les nœuds HTTPS. Cette nouvelle approche nous aidera à éliminer le risque de corruption des fichiers journaux dû à deux fichiers journaux écrivant dans le même fichier.
Validation de tous les changements de configuration dans un dépôt de code Git
L'idée derrière cette fonctionnalité est de valider et pousser toutes les modifications (qu'elles soient liées au projet ou globales) vers un dépôt de code Git. Vous pourrez utiliser ce dépôt pour partager les fichiers de configuration entre plusieurs nœuds TeamCity dans une configuration multinœuds.
Ce dépôt peut également être utilisé pour faire l'audit des modifications apportées aux paramètres de TeamCity (qu'elles aient été réalisées depuis l'interface utilisateur, l'API Rest ou les paramètres de version).
Sécurité
L'intégration continue est au cœur du processus de développement et elle est essentielle pour maintenir un workflow qui minimise les risques d'exposition des données à des tiers ou de cyberattaques. En plus de notre travail continu pour améliorer la sécurité du produit, nous allons introduire les fonctionnalités suivantes :
Intégration avec des stockages de secrets distants
Cette fonctionnalité permet à TeamCity de récupérer la valeur d'un paramètre situé dans un stockage de paramètres externe juste avant d'exécuter un build. Vous pouvez vous rendre dans l'interface utilisateur des paramètres de TeamCity pour ajouter un paramètre référençant le paramètre externe. Cette fonctionnalité sera très utile pour les équipes qui stockent des paramètres dans un stockage externe comme AWS Parameter Store, HashiCorp Vault, Azure App Configuration, Azure Key Vault, etc.
Ce dépôt peut également être utilisé pour faire l'audit des modifications apportées aux paramètres de TeamCity (qu'ils aient été réalisés depuis l'interface utilisateur, l'API Rest ou les paramètres de version).
Traitement des builds non sûrs
Nous développons une fonctionnalité qui détectera les requêtes pull et de fusion à partir des forks pour tous les hôtes VCS pris en charge. Afin de renforcer la sécurité, nous allons également implémenter une approbation manuelle obligatoire pour les builds déclenchés de cette manière.
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 souhaitons améliorer cette fonctionnalité, et voici les principaux changements que nous planifions dans un proche avenir.
Simplification de l'expérience utilisateur
L'utilisation du DSL Kotlin permet aux utilisateurs plus expérimentés de TeamCity de réutiliser plus naturellement les paramètres de configuration des builds, ce qui permet aux équipes d'économiser du temps et des efforts. Comme le DSL de Kotlin utilise des types statiques, l'utiliser dans un IDE simplifie également la découverte des API disponibles.
En même temps, nous sommes conscients que la connaissance de Kotlin ou la nécessité de travailler avec un IDE spécifique peuvent faire obstacle à la configuration de pipelines dans TeamCity. C'est pourquoi nous recherchons des moyens de simplifier l'expérience utilisateur et de faciliter encore davantage le travail avec TeamCity.
Libérez-vous des importations dans les IDE
Pour simplifier la modification des fichiers Kotlin dans les éditeurs de code autres que les IDE, nous allons supprimer la nécessité de spécifier explicitement les importations de paquets liés au DSL dans les fichiers .kt. Les importations seront gérées automatiquement du côté du serveur TeamCity.
Cela vous permettra de compiler votre code dans n'importe quel éditeur de code. TeamCity s'assurera que tout fonctionne bien.
Un DSL de base simplifié pour les petits projets
Si le DSL Kotlin vous permet de configurer très précisément des pipelines, les petits projets n'ont peut-être pas besoin de toute la complexité que cela implique. Nous allons donc simplifier le DSL de base pour les petits projets pour vous permettre de copier-coller facilement des exemples de code DSL à partir de la documentation. Cela accélérera considérablement le processus de configuration.
Expérimentation avec YAML
Le DSL Kotlin est une solution puissante pour la configuration de vos projets de CI/CD, mais certaines personnes préfèrent utiliser YAML pour la configuration du pipeline.
Nous évaluons l'intérêt d'ajouter l'option d'utiliser YAML pour configurer des projets en tant que code.
Autorisation d'ouverture du dépôt de versions de paramètres dans un système externe
Si vous utilisez le DSL Kotlin pour configurer vos versions de paramètres et apporter des modifications, TeamCity pourra vous mener au fichier correspondant dans le dépôt d'un système externe qui stocke le code voulu. Cela évitera de perdre du temps à rechercher un fichier dans tout le dépôt !
Principales améliorations de l'intégration continue
Connexion à JBA et nouveau format de licence
Nous voulons vous permettre de gérer vos licences de serveur et d'agent avec transparence et flexibilité depuis JetBrains Account. Nous voulons également que TeamCity puisse récupérer ces licences en temps réel, sans avoir à générer et à télécharger des clés de licence hors ligne.
Nous prévoyons de :
- Simplifier la gestion des licences pour les clients de TeamCity On-Premises en leur permettant de gérer leurs licences de serveurs et d'agents de build depuis leur compte JetBrains Account, et d'éviter de gérer un grand nombre de clés de licence hors ligne.
- Introduire la connexion au compte JetBrains Account pour les installations TeamCity (y compris TeamCity Professional).
Builds matricielles
Nous prévoyons d'ajouter une nouvelle fonctionnalité qui permettra d'indiquer un ensemble de paramètres à TeamCity et d'exécuter un build pour chaque combinaison possible de ces paramètres : une matrice de builds. Cette fonctionnalité est particulièrement utile si vous devez exécuter le même build ou le même test dans plusieurs environnements, par exemple, plusieurs systèmes d'exploitation, versions de Java/.NET, navigateurs, etc.
Les matrices de builds vous épargnent un temps et un travail considérables, en vous permettant de mettre au point une seule fois un ensemble de paramètres spécifiques (par exemple, le système d'exploitation et l'environnement), que vous exécuterez ensuite en parallèle sur d'autres configurations de build.
Tableaux de bord du déploiement
Nous allons permettre de sauvegarder un historique des builds déployés.
Cette nouvelle fonctionnalité vous aidera à vérifier l'état actuel de tous les déploiements, pour voir par exemple quelle version est déployée en production et en préproduction.
Vous pourrez également accéder à des rapports sur l'historique du déploiement de toutes les instances. Sur le tableau de bord de déploiement, vous trouverez une liste des instances, leur état actuel (en cours, réussite, échec), ainsi que les détails pertinents du build (horaire, agent, qui a déclenché le build, etc.).
Planification de l'exécution d'un build à un moment spécifique
Avez-vous déjà souhaité reporter l'exécution d'un build à un moment spécifique ?
Nous développons actuellement une fonctionnalité qui vous permettra de planifier l'exécution du build quand vous le souhaitez (en tenant compte des fuseaux horaires), ainsi qu'avec des horaires relatifs (p. ex., deux heures à partir de maintenant).
Le build sera immédiatement placé en file d'attente jusqu'à la date/heure d'exécution voulue.
Utilisation de ressources partagées dans les builds composites
Nous explorons la possibilité de transférer une valeur verrouillée dans un build composite à ses build dépendants. À l'avenir, nous aimerions également donner aux utilisateurs de TeamCity la possibilité de verrouiller des ressources pour un ensemble de builds liés à des dépendances d'instantanés.
Interface utilisateur de TeamCity
Comme les développeurs utilisent leur solution CI/CD tous les jours, nous voulons que TeamCity soit comme une seconde maison.
Migration des onglets dans l'interface utilisateur Sakura
À partir de la version 2022.10, l'interface utilisateur Sakura devient l'interface par défaut de TeamCity. Nous nous efforçons actuellement de parvenir à une parité totale des fonctionnalités entre les interfaces utilisateurs Classic et Sakura. Pour ce faire, nous allons réimplémenter les pages de l'interface utilisateur Classic et perfectionner le sous-système des plugins afin d'intégrer les onglets des plugins dans l'interface utilisateur Sakura.
Amélioration de l'initiation des utilisateurs à TeamCity
TeamCity est un puissant système CI/CD doté d'un grand nombre de fonctionnalités avancées. Pour aider les utilisateurs à se familiariser avec TeamCity et à configurer le logiciel selon leurs souhaits, nous allons fournir des guides d'initiation au sein de la solution. Les guides et conseils interactifs apprendront aux non initiés à utiliser TeamCity efficacement et aideront les habitués à migrer de l'interface Classic à Sakura.
Guides interactifs et projets modèles
Afin d'améliorer la prise en main par les utilisateurs, nous allons introduire des projets de démonstration modèles dans TeamCity. Avec ces projets modèles, vous pourrez essayer TeamCity sans avoir à connecter votre propre base de code à l'outil de CI/CD et obtenir votre première build valide plus rapidement.
Des guides interactifs vous aideront à avoir une vue d'ensemble des fonctionnalités de base de TeamCity directement dans l'interface utilisateur. Ces guides présenteront différents scénarios et cas d'utilisation pour vous familiariser avec TeamCity plus rapidement.
Performances de l'interface utilisateur Sakura
Nous travaillons à l'amélioration des performances pour les plus grandes installations de TeamCity. Nous nous concentrons principalement sur les agents et les pages de projets. Notre objectif est de réduire les mesures de TTFB (temps de chargement du premier octet), de CLS (changements de mise en page cumulés), de TTI (délai d'interactivité), ainsi que d'autres indicateurs web essentiels. Les utilisateurs de TeamCity peuvent s'attendre à un rendu et un chargement accélérés des pages de leurs applications dans tous les navigateurs.
Interface utilisateur Sakura : onglet Problems
TeamCity donne une vue d'ensemble des problèmes existants et des investigations en cours aux niveaux du projet et du build. Les utilisateurs peuvent vérifier les erreurs de configuration du build, les tests ayant échoué, les problèmes en cours d'investigation, leur responsable et statut.
Nous sommes en train de retravailler l'interface pour donner aux utilisateurs une meilleure vue d'ensemble des tickets et de leur statut dans un projet sélectionné. Ils figurent désormais dans le même onglet : Problems.
À cet endroit, les utilisateurs pourront filtrer les problèmes selon leur type (échec des tests, problèmes de build et problèmes de configuration de build), statut (activés/désactivés) et investigateur (responsable).
Avec cette mise à jour, nous voulons fournir à nos utilisateurs une solution plus pratique et concise d'examen des problèmes de build et de leur statut.
TeamCity Pipelines
TeamCity Pipelines offrira une expérience simple et intuitive pour la création de pipelines CI/CD, alimentée par l'intelligence caractéristique des produits JetBrains.
Avec TeamCity Pipelines, notre projet consiste à reporter notre attention des étapes individuelles du processus d'automatisation des builds et des tests vers l'expérience globale de la mise en place de pipelines de livraison. TeamCity Pipelines offrira une expérience simple et intuitive pour la création de pipelines CI/CD, alimentée par l'intelligence caractéristique des produits JetBrains.
Le tout nouvel éditeur visuel de pipeline dans TeamCity Pipelines simplifie le travail avec des pipelines CI/CD, quelle qu'en soit la complexité, et s'appuie sur le moteur de CI/CD de TeamCity, qui peut gérer des charges de travail de niveau entreprise. L'assistance intelligente à la configuration intégrée à TeamCity Pipelines vous guidera à travers toutes les étapes de la configuration du pipeline et suggérera automatiquement des optimisations au cours du processus.
Voici quelques exemples de projets de nouvelles fonctionnalités pour TeamCity Pipelines :
YAML pour la configuration en tant que code (CaC)
Le DSL Kotlin est une solution puissante de configuration de vos pipelines en tant que code. Cependant, certains utilisateurs préfèrent réaliser la configuration initiale de leurs projets de CI/CD en utilisant YAML, qui est le langage le plus utilisé dans l'industrie du CI/CD.
TeamCity Pipelines laisse aux utilisateurs la possibilité d'utiliser YAML pour stocker les paramètres de build et définir les tâches et leurs dépendances.
Parallélisation des tests
TeamCity peut automatiquement paralléliser les suites de tests en utilisant un algorithme intelligent, sans entrée supplémentaire de l'utilisateur. Ce dernier doit uniquement choisir le nombre d'agents de build que ses tests doivent exécuter en parallèle. Cela contribuera à réduire de façon significative la durée de l'exécution suivante.
Zone d'essai des agents
Parfois, les utilisateurs peuvent avoir des difficultés à comprendre quels logiciels sont installés sur les agents de build TeamCity, le système d'exploitation utilisé par les différents agents et la façon dont les utilisateurs peuvent modifier les agents de build hébergés par JetBrains.
Nous aimerions développer une zone d'essai des agents qui donnera aux utilisateurs la possibilité d'exécuter leurs scripts sur l'agent sans exécuter le pipeline. De cette façon, les utilisateurs pourront se connecter aux agents de la zone d'essai pour procéder aux investigations et au débogage une fois le processus de build terminé.
Nous allons également fournir aux utilisateurs la capacité d'ouvrir des terminaux d'agent directement depuis l'interface utilisateur de TeamCity Pipelines de façon à vérifier rapidement l'environnement de l'agent et déboguer les problèmes propres à un agent donné.
Meilleure intégration avec Docker
Si les logiciels dont vous avez besoin pour votre configuration des pipelines ne sont pas disponibles sur un agent, vous pouvez exécuter vos builds dans un conteneur Docker.
The enhanced Docker integration in TeamCity Pipelines will allow you to use the autocomplete feature to find the correct Docker image from https://hub.docker.com/. Elle affiche également la liste des images Docker utilisées précédemment et fournit un lien pour chaque résultat d'image Docker trouvé. Cela va simplifier et accélérer la recherche d'une image Docker requise.
Nous sommes en train d'évaluer la possibilité de fournir une solution intuitive en cas d'absence d'une image spécifique sur Docker Hub. Les utilisateurs pourraient être en mesure de référencer un fichier Docker depuis leur dépôt de code du système de contrôle de version.
Affichage des optimisations appliquées et recommandées
Grâce à ses fonctionnalités intelligentes de parallélisation des tests, de réutilisation des builds et de mise en cache, entre autres, TeamCity permet aux organisations de réduire le temps de build de façon significative. Actuellement, TeamCity affiche le temps optimisé (gagné) pour chaque exécution de build.
Pour développer cette fonctionnalité, nous allons fournir une vue plus complète des optimisations qui ont été appliquées lors de l'exécution de la build. Nous sommes également en train de compiler la liste des optimisations susceptibles de réduire encore davantage le temps de build.
Vous pouvez vous inscrire ici pour un accès anticipé à TeamCity Pipelines.
TeamCity Cloud
Nous voulons que nos utilisateurs puissent développer sans se soucier de l'installation et de la maintenance de l'infrastructure de build. C'est pourquoi nous proposons TeamCity Cloud, une solution CI/CD gérée de A à Z, entièrement hébergée et supervisée par JetBrains. Elle dispose des mêmes fonctionnalités que la version sur site, à l'exception de plusieurs fonctionnalités administratives superflues dans l'installation cloud.
Bien que tout ce que nous développons arrive à la fois dans les versions sur site et cloud du produit, TeamCity Cloud dispose d'un certain nombre de fonctionnalités supplémentaires sur sa feuille de route :
- Agents macOS avec Apple Silicon (puces M1) Développement
- Intégration avec d'autres produits JetBrains En cours de conception
- Système de licences compatible avec l'open source En cours de conception
- Nouveaux niveaux de tarification. En cours de développement