Cloud-Funktionen
Wir möchten Ihnen mit TeamCity alles bereitstellen, was Sie für schnelle und kosteneffiziente CI/CD-Pipelines benötigen. Aus diesem Grund arbeiten wir an einer Reihe von Funktionen, mit denen Sie Ihre Builds einfacher in der Cloud einrichten und ausführen können.
Permanente Caches für Cloud-Agents
Teams, die TeamCity in der Cloud verwenden, sollten ihre Builds genauso schnell ausführen können wie mit einer lokalen Installation. Mit permanenten Cloud-Caches werden Cloud-basierte Build-Agents Build-Abhängigkeiten wie etwa Maven-Artefakte und npm-Pakete untereinander austauschen können, um Ihnen Zeit und Netzwerkkosten zu ersparen.
Sogar die Umwelt profitiert, wenn Sie weniger Downloads benötigen. Sie sparen Strom und verringern so Ihren CO2-Ausstoß. Nicht nur Ihre Builds werden also mit dieser Funktion schneller grün, sondern auch unser Planet.
Überarbeitete Verwaltung von AWS-Zugangsdaten
Wir haben vor Kurzem mit AWS Connection ein neues Verwaltungssystem für Zugangsdaten veröffentlicht, das den Build-Features und Cloud-Integrationen von TeamCity temporäre AWS-Zugangsdaten bereitstellt, deren Rechte passend zur jeweiligen Aufgabe vergeben werden. Unser nächster Schritt ist die Unterstützung von AWS Connection in allen verfügbaren TeamCity-Plugins. Dies erspart Ihrem Team die manuelle Konfiguration des Zugriffs auf EC2, ECR, S3 und andere Ressourcen.
Standardmäßige Microsoft-Azure-Unterstützung
Immer mehr unserer Kunden sind geneigt, Build-Agents in der Cloud auszuführen, da sie so die Kapazitäten ihrer Pipelines bei Bedarf schnell erhöhen können. Um die Migration zu Microsoft Azure zu unterstützen, wollen wir das Azure-Plugin verbessern und mit TeamCity bündeln.
Image-Builder für Build-Agents
Mit dem Image-Builder von TeamCity können Sie benutzerdefinierte VM-Images von TeamCity-Build-Agents für verschiedene Umgebungen erstellen. Auf diese Weise können Sie Ihren Build-Ablauf mit voreingestellten Versionsverwaltungen, Build-Abhängigkeiten, Docker-Images usw. beschleunigen.
Ausführungsmodus
Wir würden gerne einen verbreiteten Scheduler wie Kubernetes, HashiCorp Nomad, AWS ECS oder ähnliches unterstützen, um einfache Build-Aufgaben auszuführen, ohne einen Build-Agent definieren und warten zu müssen.
Dadurch könnten Sie mit der Einrichtung von Build-Konfigurationen für Ihr Projekt beginnen, ohne sich Gedanken über die Worker zu machen, die Ihre Builds ausführen sollen.
Ein solcher Ansatz ist praktisch für kleine und einfache Aufgaben, die kein lokales Caching von VCS-Roots, Abhängigkeiten und dergleichen erfordern. Außerdem werden Ressourcen durch den Einsatz von Schedulern besser ausgelastet. Die Scheduler können von Haus aus mehrere Aufgaben parallel auf demselben Cluster-Knoten ausführen.
Von JetBrains gehostete Agents
Wir sind dabei, die Palette der TeamCity-Cloud-Agents, die von JetBrains gehostet werden, zu erweitern. Dazu gehört das erneute Anbieten von minutengenauen macOS-Agents und die Bereitstellung von ARM-basierten Linux-Agents.
Mandantenfähigkeit in TeamCity
Derzeit stellt TeamCity Cloud für jedes Kundenunternehmen einen eigenen Server bereit. Wir prüfen die Möglichkeit, mehrere Projekte auf demselben Server zu hosten. Dies würde die Kosten senken und vielleicht sogar eine kostenlose Version von TeamCity Cloud ermöglichen.
Build-Runner und Integrationen
Entwickler*innen auf der ganzen Welt sind begeistert von der engen Integration zwischen TeamCity und externen Build-Tools und Services. Wir legen großen Wert darauf, in dieser Hinsicht die bestmögliche Unterstützung zu bieten. Im Folgenden finden Sie eine Liste der neuen Integrationsfunktionen, die wir einführen möchten.
Build-Auslösung durch das Build-Feature „Pull-Requests“
Das Build-Feature Pull-Requests erweitert derzeit die Branch-Spezifikationen eines VCS-Roots um Branches von offenen Pull-Requests, die bestimmten Filterkriterien entsprechen.
Wir möchten diese Funktion so erweitern, dass Sie Builds für eine Untermenge von Pull-Requests automatisch auslösen können, während Builds für andere Branches manuell ausgelöst werden.
Konsolidierung von Projekt- und Build-Features für Integrationen
Dieses Feature wird es Ihnen ermöglichen, eine Verbindung (etwa zu GitHub) auf der Projektebene zu konfigurieren. Sie können direkt in den Verbindungseinstellungen festlegen, ob TeamCity Pull-Requests und Informationen aus Issue-Trackern abrufen soll, und Sie können angeben, welche Build-Konfigurationen den Status veröffentlichen müssen.
Mit dieser Funktion sparen Sie viel Zeit, denn Sie können die Einstellungen einmalig auf der Projektebene konfigurieren.
Bedienoberfläche für Token-Verwaltung
OAuth-Token, die über Connections erzeugt werden, werden in einem internen TeamCity-Tokenspeicher gespeichert. Derzeit werden sie aus dem Speicher abgerufen, wenn bestimmte Einstellungen (z. B. ein VCS-Root oder ein Build-Feature) über die Bedienoberfläche konfiguriert werden.
Wir möchten nun eine Bedienoberfläche für die Verwaltung von Token einführen. Damit könnten Sie die Verwendung und die Gültigkeitsbereiche Ihrer Token überprüfen und die folgenden weiteren Möglichkeiten nutzen:
- Anzeige von Token-IDs, Verbindungen, dem Account, mit dem der Token erzeugt wurde usw.
- Erzeugung neuer Token, sodass sie über eine ID referenziert werden können (z. B. in DSL-Code).
- Löschen von Token aus dem Speicher.
- Einsehen und Bearbeiten der Projekt-Gültigkeitsbereiche von Token.
- Anzeige der Token-Verwendung in verschiedenen Bereichen.
Automatisierte VCS-basierte Einrichtung neuer Projekte
Große Unternehmen lieben die Skalierungsfähigkeiten von TeamCity, das Tausende Build-Agents und Zehntausende Projekte ermöglicht. Ab einer bestimmten Schwelle kann das Anlegen neuer Projekte jedoch zu einer Belastung werden, die sich zudem bei jedem neuen Vorhaben wiederholt.
Mit dieser Funktion prüfen wir die Möglichkeit, automatisch ein TeamCity-Projekt anzulegen, wenn ein neues .teamcity-Repository erstellt wird.
Pull-Request-Unterstützung in der Bedienoberfläche
TeamCity bietet gezielte Unterstützung für GitHub-Pull-Requests. Aus der Sicht von TeamCity sind Pull-Requests ein spezieller Branch-Typ. Wir werden diese Branches in der Bedienoberfläche kennzeichnen, damit sie klar erkennbar sind.
Unterstützung für GitHub Checks
Durch die Unterstützung von GitHub Checks werden wir von GitHub stammende Daten nutzen, um mehr Informationen über die Ereignisse während des Buildvorgangs bereitzustellen.
Diese Funktion bietet die folgenden zentralen Vorteile:
- Erweiterte Hypertext-Berichte anstelle von einfachen Statusinformationen.
- Möglichkeit, bestimmte Stellen im Quellcode mit Anmerkungen zu versehen (z. B. für Inspektionen).
Zusätzliche Filterkriterien für das Build-Feature Pull-Requests
Derzeit bietet TeamCity im Build-Feature für Pull-Requests nur einen einzigen Filter für den Zielbranch. Wir arbeiten daran, weitere Filter nachzureichen, z. B. Review-Status, Labels, Autorenrollen und mehr.
Game-Entwicklung
TeamCity bietet einen Leistungsumfang und eine Flexibilität, die kein anderes CI-System erreicht. Kein Wunder, dass TeamCity eine der populärsten CI-Lösungen für die Game-Entwicklung ist. Wir haben damit begonnen, den Mehrwert zu erforschen, den das Tool in dieser Branche erbringen kann und haben dabei drei Hauptbereiche im Blick:
- Unity-Unterstützung.
- Unreal-Engine-Unterstützung.
- Allgemeine CI/CD-Workflows in der Game-Entwicklung.
Sie haben Interesse an der Verwendung von TeamCity bei Ihrer Game-Entwicklung? Wir laden Sie ein, sich hier anzumelden, um an unserer Forschung teilzunehmen.
Verbesserte Perforce-Integration
TeamCity bietet eine native Integration mit Perforce Helix Core, einem der meistverwendeten Versionierungssysteme in der Game-Entwicklung. Im Folgenden finden Sie unsere Pläne für die Perforce-Unterstützung.
Automatische Löschung von Perforce-Workspaces, die von TeamCity erstellt wurden
Durch das Agent-basierte Checkout aus Perforce werden Perforce-Workspaces angelegt. Wenn ein TeamCity-Agent nicht mehr verwendet wird, verbleiben diese Workspaces auf dem Perforce-Server.
Um den Verbrauch von Serverressourcen zu verringern, implementieren wir die automatische Löschung von Perforce-Workspaces, die TeamCity für nicht länger aktive TeamCity-Agents erstellt hat.
Mehr Kontrolle über Helix-Swarm-Review-Kommentare vom Commitstatus-Publisher
Derzeit veröffentlicht der Commitstatus-Publisher Informationen über jede Buildphase (In Warteschlange, Gestartet, Erfolgreich/Fehlgeschlagen usw.), was manchmal zu viel sein kann.
Wir werden Ihnen mehr Kontrolle darüber geben, welche Kommentare versendet werden und durch welche Statusänderungen sie ausgelöst werden.
Benutzerdefinierter Name für Perforce-Workspace beim Agent-basierten Checkout
Derzeit wird der beim Agent-basierten Checkout erzeugte Perforce-Workspace von TeamCity automatisch benannt. Wir planen eine Option, mit der Sie ein Muster für den Workspace-Namen vorgeben können. In diesem Muster können folgende Informationen verwendet werden:
- Projekt-ID und Konfigurations-ID.
- Externe ID des VCS-Roots.
- Name des Checkout-Verzeichnisses.
Unterstützung für Unreal Engine
Die Unreal Engine ist eine der populärsten Engines für die Game-Entwicklung. Wir arbeiten an einem neuen Unreal-Engine-Plugin, das innerhalb von TeamCity die folgenden Möglichkeiten bereitstellen soll:
- Erkennung von Unreal-Engine-Installationen auf Build-Agents.
- Spezieller Unreal-Engine-Runner.
- Automatische Erkennung von Unreal-Engine-Buildschritten.
- Strukturierte Buildprotokolle mit Hervorhebung von Problemen.
- Testberichte.
Multinode-Konfiguration
Durch das Zusammenschalten mehrerer TeamCity-Knoten können Sie mit Ihrem CI/CD-Workflow ein völlig neues Niveau an Leistung und Zuverlässigkeit erreichen. Wir sind dabei, die Arbeitsweise von TeamCity in Clusterumgebungen zu verbessern, indem wir neue Funktionen für Multinode-Installationen implementieren.
Verbesserte Verfügbarkeit
Serverwartungen sollten nicht das Ausführen von Builds verhindern. Wir wollen verstärkt in Funktionen investieren, die die Verfügbarkeit von TeamCity erhöhen, einschließlich der automatischen Umwandlung von sekundären Knoten in Hauptknoten. Außerdem werden wir die Notwendigkeit eines gemeinsamen Datenverzeichnisses in Multinode-Installationen weiter verringern.
Verbesserte Weitergabe von Änderungen in Konfigurationsdateien
Wir planen, alle Konfigurationsdateien in einem lokalen Git-Repository zu speichern. Dieses Repository kann für die gemeinsame Nutzung von Konfigurationsdateien in den TeamCity-Knoten einer Multinode-Installation verwendet werden.
Dadurch können wir Transaktionsbenachrichtigungen über alle Änderungen an diesen Dateien versenden und die Atomarität dieser Änderungen sowie die Atomarität der Änderungsbenachrichtigungen an Sekundärknoten sicherstellen.
Eigenständiger Buildprotokoll-Service
In Multinode-Installationen arbeiten alle Knoten mit Buildprotokoll-Dateien, die in einem gemeinsamen Datenverzeichnis gespeichert sind. Meistens ist ein Knoten der „Besitzer“ der Protokolldatei für einen bestimmten Build. Dieser Knoten kann in die Datei schreiben, während andere Knoten sie nur lesen können.
Falls ein TeamCity-Knoten feststellt, dass der Besitzerknoten der Protokolldatei abgestürzt ist (obwohl dieser in Wirklichkeit einwandfrei funktioniert), könnte ein anderer Knoten beginnen, in dieselbe Protokolldatei zu schreiben und diese dadurch beschädigen.
Wir möchten einen eigenständigen Buildprotokoll-Service implementieren, der von jedem Knoten aus per HTTPS zugänglich ist. Durch diesen neuen Ansatz können wir ausschließen, dass zwei Knoten schreibend auf dieselbe Datei zugreifen und dadurch Protokolldateien beschädigt werden.
Commit aller Konfigurationsänderungen in ein Git-Repository
Die Idee hinter diesem Feature ist es, alle Änderungen (sowohl projektbezogene als auch globale) in ein bestimmtes Git-Repository zu committen und zu pushen. Dieses Repository kann dann von allen TeamCity-Knoten einer Multinode-Installation als Speicher für Konfigurationsdateien verwendet werden.
Dieses Repository kann auch für das Auditing aller Änderungen an den TeamCity-Einstellungen verwendet werden, ganz gleich, ob diese über die Bedienoberfläche, die Rest-API oder über versionierte Einstellungen vorgenommen wurden.
Sicherheit
Continuous Integration steht im Mittelpunkt des Entwicklungsprozesses und ist entscheidend für die Aufrechterhaltung eines Workflows, der das Risiko von Datenzugriffen durch Dritte sowie von Cyberangriffen minimiert. Neben unserer kontinuierlichen Arbeit an sicherheitsrelevanten Produktverbesserungen werden wir die folgenden Funktionen einführen:
Integration mit entfernten Geheimwert-Speichern
Diese Funktion ermöglicht es TeamCity, Parameterwerte unmittelbar vor der Ausführung eines Builds aus einem externen Parameterspeicher abzurufen. Sie können die Parameter-UI von TeamCity öffnen und einen Parameter anlegen, der auf den externen Parameter verweist. Diese Funktion ist nützlich für Teams, die Parameter in externen Speichern wie AWS Parameter Store, HashiCorp Vault, Azure App Configuration, Azure Key Vault usw. speichern.
Dieses Repository kann auch für das Auditing aller Änderungen an den TeamCity-Einstellungen verwendet werden, ganz gleich, ob diese über die Bedienoberfläche, die Rest-API oder über versionierte Einstellungen vorgenommen wurden.
Umgang mit unsicheren Builds
Wir arbeiten an einer Funktionalität, die Pull- und Merge-Requests aus Forks in allen unterstützten VCS-Hosts erkennt. Um die Sicherheit zu erhöhen, werden wir eine obligatorische manuelle Genehmigung für Builds einführen, die auf diese Weise ausgelöst werden.
Konfiguration als Code
Dank der Ausdruckskraft der Kotlin-DSL gehen immer mehr unserer Benutzer dazu über, ihre CI/CD-Konfigurationen als Code zu speichern. Wir wollen dieses Feature verbessern, und im Folgenden geben wir Ihnen einen Überblick über die wichtigsten Änderungen, die wir für die nahe Zukunft planen.
Vereinfachte Nutzungserfahrung
Mit der Kotlin-DSL können erfahrene TeamCity-Benutzer*innen Build-Konfigurationen einfacher wiederverwenden und dadurch Zeit und Mühe sparen. Da die Kotlin-DSL statisch typisiert ist, vereinfacht die Verwendung einer IDE zudem das Auffinden der verfügbaren APIs.
Gleichzeitig sollten Kotlin-Kenntnisse oder die Verwendung einer bestimmten IDE keine Voraussetzung für die Konfiguration von Pipelines in TeamCity sein. Deshalb untersuchen wir Möglichkeiten, die Nutzungserfahrung zu optimieren und die Arbeit mit TeamCity noch einfacher zu gestalten.
Keine Importe in IDEs
Für eine einfachere Bearbeitung von Kotlin-Dateien in Code-Editoren, die nicht zu einer IDE gehören, sollen DSL-bezogene Paketimporte in .kt-Dateien nicht mehr explizit angegeben werden müssen. Stattdessen sollen die Importe auf der TeamCity-Serverseite automatisch gehandhabt werden.
Dadurch können Sie den Code in jedem Code-Editor kompilieren. TeamCity wiederum sorgt dafür, dass der Code tatsächlich funktioniert.
Vereinfachte Basis-DSL für kleine Projekte
Mit der Kotlin-DSL können Sie Pipelines exakt nach Bedarf konfigurieren. Allerdings benötigen kleinere Projekte möglicherweise nicht die gesamte Komplexität, die die Kotlin-DSL mit sich bringt. Daher werden wir eine vereinfachte Basis-DSL für kleinere Projekte einführen, damit Sie unkompliziert DSL-Codebeispiele aus der Dokumentation einfügen können. Dies wird den Konfigurationsprozess erheblich beschleunigen.
Experimente mit YAML
Die Kotlin-DSL bietet zwar eine leistungsstarke Möglichkeit zur Konfiguration von CI/CD-Projekten, manche Anwender*innen könnten sich jedoch mit der Verwendung von YAML für die Pipeline-Konfiguration wohler fühlen.
Wir prüfen die Möglichkeit, YAML als Option für die codebasierte Konfiguration von Projekten anzubieten.
Öffnen von Repositories für versionierte Einstellungen in externen Systemen
Wenn Sie die Kotlin-DSL zum Konfigurieren Ihrer versionierten Einstellungen verwenden und Änderungen vornehmen müssen, werden Sie von TeamCity aus zu der Repository-Datei in einem externen System navigieren können, die den entsprechenden Code enthält. Dies erspart Ihnen die Suche nach der richtigen Datei im Repository.
Verbesserungen in den CI-Kernfunktionen
JBA-Login und neues Lizenzformat
Wir möchten Ihnen die Möglichkeit geben, Ihre Server- und Agent-Lizenzen transparent und flexibel über Ihren JetBrains-Account zu verwalten. Außerdem soll TeamCity diese Lizenzen in Echtzeit abrufen können, ohne dass Sie Offline-Lizenzschlüssel generieren und herunterladen müssen.
Wir planen Folgendes:
- Vereinfachte Lizenzverwaltung für TeamCity-On-Premises-Kunden, indem Server- und Build-Agent-Lizenzen über den JetBrains-Account verwaltet werden können, ohne sich um eine Vielzahl von Offline-Lizenzschlüsseln kümmern zu müssen.
- Anmeldung in TeamCity-Installationen (einschließlich TeamCity Professional) über den JetBrains-Account.
Matrix-Builds
Wir planen eine neue Funktion zur Ausführung von „Matrix-Builds“ – dabei führt TeamCity für jede Kombination eines gegebenen Parametersatzes einen Build aus. Diese Funktion ist besonders nützlich, wenn Sie denselben Build oder Test in verschiedenen Umgebungen ausführen müssen, z. B. auf unterschiedlichen Betriebssystemen, mit unterschiedlichen Java/.NET-Versionen, Browsern usw.
Matrix-Builds reduzieren den Zeit- und Arbeitsaufwand erheblich, da Sie bestimmte Parameter (z. B. Betriebssystem und Umgebung) einmalig festlegen und dann parallel auf andere Build-Konfigurationen anwenden können.
Deployment-Dashboards
Wir werden Ihnen die Möglichkeit bieten, den Verlauf der bereitgestellten Builds zu speichern.
Mit dieser neuen Funktion werden Sie den aktuellen Status aller Deployments überprüfen können – z. B. welche Version in der Produktion und welche auf dem Staging-Server eingesetzt wird.
Berichte über den Deployment-Verlauf aller Instanzen werden ebenfalls verfügbar sein. Das Deployment-Dashboard wird eine Liste der Instanzen mit ihrem aktuellen Status (In Ausführung, Erfolgreich, Fehlgeschlagen) und relevanten Build-Details (Zeitpunkt, Agent, Auslöser des Builds usw.) enthalten.
Zeitgesteuertes Ausführen von Builds
Haben Sie sich schon einmal gewünscht, einen Build nicht sofort, sondern zu einer vorgegebenen Zeit ausführen zu können?
Wir arbeiten an einem Feature, mit dem Sie den Buildvorgang zu einem bestimmten Zeitpunkt (inkl. Zeitzonenangabe) oder mit einer bestimmten Verzögerung (z. B. in zwei Stunden) starten können.
Der Build wird sofort in die Warteschlange gestellt und zur geplanten Zeit ausgeführt.
Verwendung von geteilten Ressourcen in Composite-Builds
Wir prüfen die Möglichkeit, Werte aus einem Composite-Build an abhängige Builds weiterzugeben. In Zukunft möchten wir TeamCity-Benutzer*innen außerdem die Möglichkeit bieten, die Ressourcen für einige über Snapshot-Abhängigkeiten verknüpfte Builds zu sperren.
Die TeamCity-UI
Entwickler*innen nutzen ihr CI/CD-System jeden Tag. Daher möchten wir ihnen mit TeamCity eine angenehme Erfahrung bieten.
Tab-Migration in die Sakura-UI
Seit Version 2022.10 ist die Sakura-UI die Standard-Bedienoberfläche von TeamCity. Wir arbeiten derzeit an der vollständigen Funktionsparität zwischen der klassischen und der Sakura-Bedienoberfläche. Dazu werden wir Seiten aus der klassischen Bedienoberfläche neu implementieren und das Plugin-Subsystem optimieren, um Plugin-Tabs in die Sakura-UI zu integrieren.
Verbesserungen beim TeamCity-Onboarding
TeamCity ist ein leistungsstarkes, modernes CI/CD-System mit einem großen Funktionsumfang. Um Benutzer*innen dabei zu helfen, sich in TeamCity einzuarbeiten und die Software genau nach ihren Wünschen zu konfigurieren, werden wir innerhalb des Systems Onboarding-Anleitungen bereitstellen. Die interaktiven Anleitungen und Tipps unterstützen Neulinge bei der effektiven Nutzung von TeamCity, und erfahrenen Benutzer*innen helfen sie bei der Migration von der klassischen zur Sakura-Bedienoberfläche.
Interaktive Anleitungen und Projektvorlagen
Um das Onboarding zu erleichtern, werden wir Demo-Projektvorlagen in TeamCity einführen. Mithilfe dieser Vorlagen können Sie TeamCity ausprobieren, ohne Ihren eigenen Codebestand mit dem CI/CD-Tool verbinden zu müssen, sodass Sie schneller Ihren ersten erfolgreichen Buildlauf ausführen können.
Interaktive Anleitungen vermitteln Ihnen einen Überblick über die wichtigsten TeamCity-Funktionen direkt in der grafischen Bedienoberfläche. Die Anleitungen zeigen unterschiedliche Szenarien und Anwendungsfälle, um Sie schneller mit TeamCity vertraut zu machen.
Performance der Sakura-UI
Wir arbeiten daran, die Performance großer TeamCity-Installationen zu verbessern. Unser Hauptaugenmerk liegt auf Agents und Projektseiten. Wir streben Verbesserungen bei der Zeit zum ersten Byte, dem Cumulative Layout Shift, der Zeit zur Interaktivität sowie bei anderen wichtigen Kennzahlen („Web Vitals“) an. Dadurch wird das Laden und Anzeigen der TeamCity-Anwendungsseiten in allen Browsern beschleunigt.
Sakura-UI: Problems-Tab
TeamCity bietet einen Überblick über aktuelle Probleme und Untersuchungen auf der Projekt- und Build-Ebene. Benutzer*innen können Build-Konfigurationsfehler, fehlgeschlagene Tests und in Untersuchung befindliche Probleme überprüfen, inklusive Status und bearbeitender Person.
Wir haben die Bedienoberfläche überarbeitet, um im ausgewählten Projekt einen besseren Überblick über alle Probleme sowie deren Status zu geben. Sie finden diese Übersicht auf dem Tab Problems.
Hier können Probleme nach Typ (fehlgeschlagene Tests, Build-Probleme und Build-Konfigurationsprobleme), Status (stummgeschaltet oder nicht) und beauftragter Person gefiltert werden.
Mit diesem Update möchten wir unseren Benutzer*innen eine unkompliziertere und kompaktere Möglichkeit bieten, bestehende Probleme und deren Status zu überprüfen.
TeamCity Pipelines
Basierend auf der charakteristischen Intelligenz der JetBrains-Produkte wird TeamCity Pipelines eine einfache und intuitive Erfahrung bei der Erstellung von CI/CD-Pipelines bieten.
Mit TeamCity Pipelines wollen wir den Schwerpunkt von einzelnen Schritten der Build- und Testautomatisierung auf die Gesamterfahrung bei der Einrichtung von Delivery-Pipelines verlagern. Basierend auf der charakteristischen Intelligenz der JetBrains-Produkte wird TeamCity Pipelines eine einfache und intuitive Erfahrung bei der Erstellung von CI/CD-Pipelines bieten.
Der brandneue visuelle Pipeline-Editor von TeamCity Pipelines vereinfacht die Arbeit mit CI/CD-Pipelines unabhängig von der Komplexität. Im Hintergrund wird dabei die CI/CD-Engine von TeamCity verwendet, die Workloads auf Enterprise-Ebene bewältigen kann. Die in TeamCity Pipelines integrierte intelligente Konfigurationshilfe führt Sie durch alle Schritte der Pipeline-Konfiguration und schlägt dabei automatisch Optimierungen vor.
Hier sind einige der neuen Features, an denen wir im Zusammenhang mit TeamCity Pipelines arbeiten:
Codebasierte Konfiguration mittels YAML
Die Kotlin-DSL bietet eine leistungsstarke Möglichkeit, Ihre Pipelines mittels Programmcode zu konfigurieren. Für manche Benutzer*innen könnte es jedoch einfacher sein, ihre CI/CD-Projekte mit der im CI/CD-Bereich weit verbreiteten Sprache YAML zu konfigurieren.
TeamCity Pipelines wird die Möglichkeit bieten, zum Speichern von Build-Einstellungen und zum Definieren von Jobs und deren Abhängigkeiten YAML zu verwenden.
Testparallelisierung
TeamCity kann Testsuiten mithilfe eines intelligenten Algorithmus automatisch parallelisieren, ohne Benutzereingriffe zu erfordern. Benutzer*innen müssen nur noch festlegen, auf wie vielen Build-Agents ihre Tests parallel ausgeführt werden sollen. Dies trägt beim nächsten Durchlauf zu einer erheblichen Reduzierung der Build-Zeiten bei.
Agent-Playground
Manchmal ist es aus Benutzersicht schwierig zu überblicken, welche Software auf den TeamCity-Build-Agents installiert ist, welches Betriebssystem die Agents verwenden und wie Benutzer*innen die von JetBrains gehosteten Build-Agents anpassen können.
Wir würden gerne eine Art Testwiese für Agents bereitstellen, die Benutzer*innen die Möglichkeit gibt, ihre Skripte auf einem Agent auszuführen, ohne die Pipeline zu starten. Auf diese Weise könnten Benutzer*innen nach Abschluss eines Builds zu Untersuchungs- und Debugging-Zwecken eine Verbindung zu Playground-Agents herstellen.
Wir werden Benutzer*innen außerdem die Möglichkeit geben, Agent-Terminals direkt aus der TeamCity-Pipelines-UI heraus zu öffnen, um sich unkompliziert auf dem Agent-System umzusehen und Probleme auf dem Agent zu beheben.
Verbesserte Docker-Integration
Wenn eine für Ihre Pipeline-Konfiguration benötigte Software nicht auf einem Agent verfügbar ist, können Sie Ihre Builds auch in einem Docker-Container ausführen.
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/. Außerdem wird eine Liste der zuvor verwendeten Docker-Images angezeigt und ein Link für jedes gefundene Docker-Image bereitgestellt. Dadurch kann das benötigte Docker-Image einfacher und schneller lokalisiert werden.
Wir suchen nach einer benutzerfreundlichen Lösung für den Fall, dass ein bestimmtes Image nicht in Docker Hub vorhanden ist. Vielleicht könnten Benutzer*innen dann eine Docker-Datei aus ihrem aktuellen VCS-Repository verwenden.
Anzeige von angewendeten und empfohlenen Optimierungen
Durch intelligente Testparallelisierung, Wiederverwendung von Builds, Cache-Funktionen und andere Features kann TeamCity Unternehmen dabei helfen, ihre Buildzeiten erheblich zu reduzieren. Derzeit zeigt TeamCity die gesamte optimierte (ersparte) Zeit pro Buildlauf an.
Um diese Funktionalität zu erweitern, werden wir eine umfassendere Übersicht darüber bereitstellen, welche Optimierungen bei einem Buildlauf angewendet wurden. Wir wollen auch eine Liste der möglichen Optimierungen bereitstellen, mit denen die Buildzeit weiter reduziert werden kann.
Zur Teilnahme am Early-Access-Programm für TeamCity Pipelines können Sie sich hier anmelden.
TeamCity Cloud
Wir möchten unserer Benutzergemeinde die Möglichkeit geben, sich vollständig auf die Entwicklung zu konzentrieren, ohne sich um Installationen und Wartungsarbeiten an der Build-Infrastruktur kümmern zu müssen. Deshalb bieten wir TeamCity Cloud an – eine vollständig gemanagte CI/CD-Lösung, die in ihrer Gesamtheit von JetBrains gehostet und verwaltet wird. Sie bietet die gleiche Funktionalität wie die lokal installierte Version, mit der Ausnahme einiger Verwaltungsfunktionen, die in Cloud-Installationen nicht benötigt werden.
Während wir alle Produktfunktionen in beiden Versionen bereitstellen, haben wir für TeamCity Cloud eine Reihe zusätzlicher Features auf der Roadmap:
- macOS-Agent mit Apple-Chips (M1) In Entwicklung
- Integration mit anderen JetBrains-Produkten In Entwurfsphase
- Open-Source-freundliche Lizenzierung In Entwurfsphase
- Neue Preisstufen. In Entwicklung