Des Kaisers neue Kleider

Aus VSTS wird Azure DevOps – mehr als nur ein neuer Name?
Keine Kommentare

Das Jahr 2018 hat für Nutzer der Microsoft-ALM-/DevOps-Plattformen TFS und VSTS durch zwei große Ankündigungen mehrere gedankliche Neuausrichtungen bedeutet: Zum einen war da im Frühjahr die Absichtserklärung von Microsoft, GitHub für 7,5 Mio. US-Dollar zu kaufen, zum anderen die Umbenennung von VSTS und TFS zu Azure DevOps bzw. Azure DevOps Server in der Sommerphase.

Im Folgenden wollen wir beide Themen aufgreifen und zu Beginn das „Warum?“ etwas genauer anschauen; anschließend wird es um das „Wie manifestiert sich die Umbenennung im Produkt?“ bzw. „Was gibt es für neue Features?“ gehen. Einen weiteren inhaltlichen Schwerpunkt wird die Betrachtung des Zusammentreffens von GitHub und Azure DevOps darstellen, bzw. die Erkenntnis, dass Open Source mit Azure DevOps sich nicht ausschließt, sondern Geld spart und die Produktivität fördert.

Raider heißt jetzt Twix aber sonst ändert sich nix?

Das Umbenennen (oder neudeutsch Rebranding) von Microsoft-Produktnamen scheint für so manchen Nutzer schon eine Tradition zu sein. Im TFS-Cloud-Umfeld haben wir mittlerweile auch schon die eine oder andere Namensänderung durchlaufen: 2011 Team Foundation Service, 2013 Visual Studio Online (VSO) und 2015 Visual Studio Team Services (VSTS). Warum jetzt aber schon wieder ein neuer Name? Im Microsoft-Universum gibt es eine überschaubare Anzahl an „starken“ Markennamen. Exemplarisch seien Visual Studio, Azure, Office 365 oder Xbox genannt. An diese Marken gliedern sich wiederum die eigentlichen Produkte an. TFS heißt beispielsweise nicht nur Team Foundation Server, sondern formal gesehen Visual Studio Team Foundation Server. Und genau hier liegt aus Sicht von Microsoft das Problem. Mit dem Markennamen ist auch eine gewisse Erwartungshaltung des Nutzers verbunden. Bezogen auf den TFS suggeriert das Visual Studio im Namen gerade für viele, die nicht Visual Studio als Entwicklungsumgebung nutzen, dass der TFS nur für .NET-Entwickler funktionieren würde. Betrachtet man die Entwicklung des TFS, erkennt man, dass die ersten Versionen 2005 und 2008 tatsächlich sehr stark an die .NET-Plattform gekoppelt waren. Mittlerweile hat sich das gesamte Umfeld allerdings massiv verändert und zu einer offenen Technologieplattform entwickelt. 2005 war Microsoft im Allgemeinen noch massiv gegen Open Source und zehn Jahre später ist das Unternehmen aus der Open-Source-Community nicht mehr wegzudenken. Auch das TFS-Entwicklungsteam hat hier eine gewisse Vorreiterrolle eingenommen. Beispiele sind die Integration von Git als zweites Versionskontrollsystem mit der Version TFS 2015 oder nativer Build-Agent-Support für Linux und Mac OS X.

Unabhängig von diesen Bemühungen ist aber leider selbst im Jahr 2018 die Wahrnehmung von vielen Entwicklern außerhalb der Microsoft-Technologiewelt, dass TFS nur mit .NET sinnvoll zu verwenden ist, und das ist schlichtweg falsch. Mit dem neuen Namen versucht Microsoft jetzt eine Art Befreiungsschlag. Die Marke Azure ist für Microsoft eine Art Leuchtturm. Azure steht für Offenheit und Technologievielfalt. Das gleiche Gedankengut teilen auch TFS und VSTS, sodass jetzt die neuen Namen Azure DevOps für den Cloud-Service und Azure DevOps Server für den On-Premises-Server sind. Auf DevOps selbst muss an dieser Stelle nicht mehr genauer eingegangen werden, da man an diesem Thema gefühlt überhaupt nicht mehr vorbeikommt. DevOps als Philosophie wird dabei als der nächste Schritt nach Agile betrachtet.

Hat jetzt Microsoft etwa nur die Beschilderung des Produkts geändert oder habe ich als Nutzer auch etwas davon? Der erste große Punkt, der bei diesem Release auffällt, ist, dass jetzt die Services der Plattform als Gesamteinheit oder als getrennte einzelne Services nutzbar sind. Die gesamte Plattform trägt dabei den Namen Azure DevOps bzw. Azure DevOps Server. Im Gegensatz dazu tragen die einzelnen Services die Namen Azure Boards (Work-Item-Tracking, Backlogs, Enterprise-Portfolio-Management), Azure Repos (Git Repositories, Team Foundation Server Version Control), Azure Pipelines (alles rund um CI/CD als Weiterentwicklung des TFS/VSTS-Build- und Release-Managements), Azure Artifacts (Package Management) und Azure Test Plans (Testmanagement und Ausführung). In Unternehmen, die eine komplett neue Entwicklungslandschaft definieren, ist der Einsatz all dieser Teile die erste Wahl. Es gibt jedoch viele Fälle, in denen nur ein Teil benötigt wird. Das kann sein, weil es für andere Teile bereits gute Lösungen gibt, beispielsweise wenn ein Unternehmen eine gut ausgestattete Testmanagementumgebung hat, aber für die agile Planung und die CI/CD Pipeline eine durchgängige Lösung sucht. Des Weiteren gibt es die Fälle, in denen beispielsweise eine Fachabteilung eine Möglichkeit für agiles Anforderungsmanagement sucht oder schlichtweg ihre Arbeit mit den Azure Boards organisieren möchte. In beiden Szenarien ist es nun möglich, nur die benötigten Teile zu verwenden (Abb. 1) und die anderen, nicht benötigten Services einfach zu deaktivieren. Aus Sicht von Microsoft wird dadurch eine größere und breitere Zielgruppe besser ansprechbar.

Abb. 1: Aktivierung/Deaktivierung einzelner Azure DevOps Services

Abb. 1: Aktivierung/Deaktivierung einzelner Azure DevOps Services

Das neue UI

Neben der Umbenennung von VSTS in Azure DevOps wurde auch ebenfalls ein neues, durchgängigeres UIKonzept für alle Benutzer etabliert. Mit dem neuen Layout wurden dabei mehrere Ziele verfolgt: Unterstützung des neuen Service-Konzepts und Verbesserung der Nutzungsmöglichkeiten der Services für den Nutzer durch ein konsistentes Design. Auch TFS/VSTS sind über die Jahre gewachsene Systeme, an denen viel verbessert und erweitert wurde; dadurch finden sich ggf. Optionen nicht an den Stellen, an denen ein Nutzer sie erwarten würde oder Navigationspfade sind unnötig lang.

Die neue UI aus Abbildung 2 folgt grob folgendem Schema: In der linken Leiste findet sich ein allgemeiner Überblicksbereich mit allgemeinen, Service-übergreifenden Funktionen wie Wiki, Dashboards und Reporting und natürlich auch die aktivierten Services (1). Links unten (6) finden sich immer kontextspezifische Einstellungen, wie z. B. der Link zu den Projekteinstellungen.

Abb. 2: Azure-DevOps-UI-Konzept

Abb. 2: Azure-DevOps-UI-Konzept

Rechts oben finden sich das Nutzerprofil (3) mit seinen Einstellungen und die Preview-Flags zur Aktivierung von Previewfunktionen. Daneben ist dort immer der Link zum Azure DevOps Marketplace zu finden. Ebenfalls befindet sich neben dem Profillink (4) auch eine Art Bereich mit den wichtigsten kontextsensitiven Funktionen bzw. eine Art Schnellstartbefehlsbereich.

Der flächenmäßig größte Bereich in der Mitte (5) ist immer zur Darstellung der Servicespezifischen Informationen gedacht. In diesem Bereich stellen alle Services bzw. die Adminseiten ihre Informationen dar. Es wird hier konsequent versucht, auf das Öffnen von zusätzlichen Browsertabs – wie in der Vergangenheit oft üblich – zu verzichten. Mittlerweile wird eher der Ansatz des kontextsensitiven Umschaltens präferiert. (2) zeigt in Form eines Bread-Crumbs-Links immer den aktuell aktiven Bereich bzw. Service an.

Azure Boards

Der erste „neue alte“ Service sind die Azure Boards. Unter ihm wurden alle Funktionalitäten bezüglich Work-Item-Tracking und der agilen Managementtools zusammengefasst. Beispiele für diesen Bereich sind das gesamte Thema Backlog-Portfolio-Management, Sprint-Backlogs, Kanban Boards sowie die Verwaltung der Sprintzyklen.

In diesen Bereich fällt auch eine weitere Änderung durch das neue UI-Konzept auf (Abb. 3). In der Vergangenheit waren Teams immer direkt unter dem Teamprojekt angeordnet, erst dann kamen die eigentlichen Services. Das ist jetzt nicht mehr der Fall, stattdessen sind die Teams jetzt unterhalb der Services zu finden. Am Beispiel der Backlogs sieht man das recht anschaulich. Klickt man beispielsweise auf Backlogs, werden alle Team-Backlogs angezeigt. Früher war das genau andersrum, d. h., es wurde erst das Team ausgewählt und alle Services haben teambezogenen Informationen dargestellt. Die Änderung war wohl notwendig, um zum einen flexibler kontextbezogen navigieren zu können und zum anderen das neue Service-Modul bezüglich An- und Abwahl einzelner Services besser zu unterstützen.

Abb. 3: Teams in Azure Boards

Abb. 3: Teams in Azure Boards

Azure Repos

Den zweiten „neuen alten“ Bereich bilden die Azure Repos. Dieser Bereich umfasst die ursprünglichen Funktionalitäten rund um das Thema Version Control (Abb. 4 und 5). Beispiele hierfür sind die Themen Git, Pull Requests, Branch Policies aber auch das gute alte zentrale Versionskontrollsystem TFVC (Team Foundation Server Version Control). Der Name von TFVC wurde wider Erwarten nicht in Azure DevOps Version Control umbenannt und wird es laut Microsoft auch nicht werden.

Abb. 4: Git in Azure Repos

Abb. 4: Git in Azure Repos

Abb. 5: TFVC in Azure Repos

Abb. 5: TFVC in Azure Repos

Im Gegensatz zu GitHub adressiert die Git-Funktionalität in Azure DevOps primär nichtöffentliche Git Repositories. Mit einer Lizenz habe ich hier als Nutzer theoretisch die Möglichkeit, unlimitiert private Git und TFVC Repositories anzulegen. Das gilt faktisch sowohl für die Anzahl als auch die Größe der jeweiligen Repositories. Dass Azure DevOps praktisch auch Riesen-Repositories handhaben kann, zeigt recht eindrucksvoll die Office- und Windows-Entwicklung mit Repository-Größen von mehr als 200 GB und über 20 Mio. Dateien.

Azure Pipelines

Der Bereich mit den in der persönlichen Wahrnehmung meisten Änderungen in den letzten Monaten ist Azure Pipelines. Unter Azure Pipelines wurden die ursprünglichen Build- und Releasemanagementbereiche zusammengefasst. Neben den fast schon üblichen Verbesserungen mit jedem Sprint, wie z. B. codebasierende YAML-Buildund -Release-Definitionen, bringt Microsoft mit der Umbenennung zwei weitere, sehr nützliche Verbesserungen mit: Das Kontingent der freien Minuten auf den Build und Release-Agents der CI/CD Pipeline für private Projekte wurde von 240 auf 1600 Minuten erhöht. Für Open-Source-Projekte stehen für Aufträge auf diesen Agenten sogar unlimitierte Minuten bereit. Die Open-Source-Projekte können dabei entweder unter Azure DevOps als Public Project oder auf einem externen System wie z. B. GitHub, GitLab, SVN, Sourceforge, usw. liegen. Microsoft hat dabei für Open-Source-Projekte die sonst übliche Limitierung von einer kostenlosen Pipeline auf zehn Pipelines erhöht. Zehn Pipelines ermöglichen exemplarisch das parallele Kompilieren auf zehn verschiedenen Build-Agenten. Wenn aber Windows nicht genug ist, dann können die zehn parallelen Builds natürlich auch mit von Microsoft vorkonfektionierten Hosted-Agent-Pools auf Windows, Linux und Mac OS X genutzt werden. Das Betriebssystem spielt dabei für Microsoft bezüglich des Sponsorings keine Rolle. Für ein Open-Source-Projekt bedeutet das, dass Microsoft für sie faktisch die kompletten CI/CD Pipelines auf Windows, Linux und Mac OS X kostenlos bereitstellt. Die zehn parallelen Builds können dabei beliebig über alle Plattformen verteilt werden. Aus Sichtweise der Autoren ist das ein sehr spannendes Angebot für Open-Source-Projekte. Dieses Angebot an die Open-Source-Community sendet ebenfalls ein starkes Signal, dass Microsoft Open-Source-Projekte sehr wichtig sind und diese nicht als Spielerei ansieht, sondern auch finanziell nicht nur für GitHub tief in die Tasche greift.

Nachfolgend möchten wir kurz auf den Workflow zur Einbindung eines Open-Source-Projekts in Azure Pipelines eingehen. GitHub und Azure DevOps sind – obwohl beides mittlerweile zu Microsoft gehört – unabhängige Plattformen. Die Integration von Azure DevOps ist deshalb auf GitHubs Seite auch nicht einfach in die eigentliche Plattform integriert, sondern verwendet die gleichen externen Erweiterungsmöglichkeiten wie alle anderen externen Partner auch: den GitHub Marketplace. Will ich auf GitHub Azure Pipelines nutzen, muss ich nicht erst ein Azure-Konto mit hinterlegter Kreditkarte anlegen, um den Service zu nutzen, sondern kann Azure Pipelines direkt und kostenlos über den GitHub Marketplace beziehen (Abb. 6). Im Hintergrund wird dann die Anbindung provisioniert. Als Ergebnis entstehen dann automatisch diverse GitHub Webhooks, die Azure DevOps über neue Aktivitäten auf GitHub informieren und eine abgespeckte Azure-DevOps-Organisation mit nur einem aktivierten Service, nämlich den Azure Pipelines, einrichten.

Abb. 6: Azure Pipelines mit GitHub verbinden

Abb. 6: Azure Pipelines mit GitHub verbinden

Nach der Anbindung von Azure Pipelines legt der Nutzer eine oder mehre YAML-basierte Build- und Release-Pipelines an. In Abbildung 7 ist der Prozess dargestellt, der sich an Abbildung 6 anschließt. Als Nutzer kann man natürlich den Prozess auch für weitere Build- und Releasedefinitionen nach einem ähnlichen Schema mehrfach durchlaufen. Nach der Verbindung von GitHub mit Azure Pipelines wählt der Nutzer das passende CI-/CD-Template und passt es ggf. an seine Bedürfnisse an. Anschließend muss er mit Save and run nur noch seine Pipeline anstoßen. Will man auf seiner GitHub-Repo-Seite ebenfalls die Build-Statusinformationen sehen, kann man das Build-Status-Badge in seine Repo-Markdown-Files integrieren.

Abb. 7: YAML-basierte Azure-Pipeline-Definition anlegen

Abb. 7: YAML-basierte Azure-Pipeline-Definition anlegen

Azure Test Plans

Abb. 8: Beispiel für Azure Test Plan

Abb. 8: Beispiel für Azure Test Plan

Formale wie explorative Tests werden in Zukunft über Azure Test Plans verwaltet und ausgeführt. Hierbei hat sich strukturell im Vergleich zur vorherigen Version von TFS bzw. VSTS nichts verändert. Für das formale Testmanagement stehen immer noch sogenannte Testpläne und Testsuits zur Verfügung, die man ineinander verschachteln kann. Die eigentliche Testdefinition findet dann in den Testfall-Work-Items statt.

In der Navigation (Abb. 8) findet der Anwender zunächst die Verwaltung der Testpläne. Die nächsten Menüpunkte lassen die Definition von Parametern, also Eingabewerten, die wiederverwendet werden, sowie Testkonfigurationen zu. Über den Menüpunkt Runs gelangt man in eine Ansicht der letzten Testdurchläufe, unabhängig davon, ob sie vom einem Build-/Releaseprozess oder Testplan erzeugt wurden.

Load test führt den Anwender zu dem Bereich der
Cloud-basierten Lasttests. Hier besteht die Möglichkeit, die Anwendung durch die wiederholte und parallelisierte Ausführung bestimmter Testschritte einer definierten (ggf. hohen) Belastung auszusetzen. Interessant hierbei ist, dass ganz verschiedene Arten der Testdefinition für die Lasttests unterstützt werden, wie in Abbildung 9 zu sehen ist.

Abb. 9: Unterstützte Lasttesttypen in Azure DevOps

Abb. 9: Unterstützte Lasttesttypen in Azure DevOps

Microsoft befindet sich im Bereich des Testmanagements seit längerer Zeit auf dem Weg in Richtung eines vollständigen Testmanagements im Web. Dabei gibt es zwei wesentliche Knackpunkte, die im Web nicht so einfach zu lösen sind: Das Verbinden auf virtuelle Umgebungen im Bereich der automatisierten Tests (früher bekannt als Lab Management) sowie das Sammeln von systemnahen Diagnosedaten (z. B. Windows Eventlog, geöffnete Prozesse einer Desktopanwendung, usw.) beim Testen einer lokal installierten Anwendung (Desktopapplikation). Bei letzterem hat Microsoft nun einen Vorstoß gewagt und einen neuen Test-Runner bereitgestellt. Die zugrunde liegende Problematik ist, dass der Browser eine Webanwendung aus Sicherheitsgründen nicht so einfach auf systemnahe Ressourcen zugreifen lässt.

Durch den neuen Azure Test Runnes ergibt sich das auch in Abbildung 10 dargestellte Bild an Test-Runnern, das in der Zukunft sicherlich wieder etwas aufgeräumt wird:

  • Web Test Runner: für formale Tests von Webanwendungen
  • Azure Test Runner: für formale Tests von Desktopanwendungen
  • Test- und Feedback-Extension (für Chrome und Firefox): für exploratives Testen von Webanwendungen und das Testen auf Mobilgeräten mittels des Diensts Perfecto Mobile
  • Microsoft Test Manager 2017 Test Runner: für formales Testen von Desktopapplikationen mit allen Diagnoseadaptern
Abb. 10: Test-Runners für die manuelle Testausführung in Azure DevOps

Abb. 10: Test-Runners für die manuelle Testausführung in Azure DevOps

Da der neue Azure Test Runner auf Basis des plattformübergreifenden Frameworks Electron implementiert ist und bereits beim Testen von Desktopapplikationen ein Aktivitätslog erstellt wird, kann man davon ausgehen, dass es sich hier um die potenzielle Ablösung des Microsoft Test Manager 2017 Test Runners (MTM) handelt. Noch immer steckt viel Funktionalität im MTM, die noch an keiner anderen Stelle abgebildet ist, aber mit dem Azure-Test-Runner geht es einen weiteren großen Schritt in Richtung der Ablösung dieser alten WPFbasierten Anwendung aus Visual-Studio-2010-Zeiten.

Azure Artifacts

Den Abschluss der Vorstellung der Azure DevOps Services bildet Azure Artifacts. Dieser neue Bereich fasst alle Funktionalitäten rund um das Thema Package Management zusammen (Abb. 11). Azure Artifacts unterstützt dabei die Platzhirsche in diesem Bereich wie NuGet für den .NET-Bereich aber auch npm für den gesamten JavaScript-Bereich. Bei diesen Typen bleibt es aber nicht, sondern Maven, Gradle, Python sowie die Universal Packages sind ebenfalls mit an Board.

Abb. 11: Anlegen eines neuen Package Management Feeds in Azure DevOps

Abb. 11: Anlegen eines neuen Package Management Feeds in Azure DevOps

In Anhängigkeit vom Package Type unterstützt das Package Management zum Zeitpunkt der Drucklegung nicht nur die einfache Ablage und Versionierung der Artefakte in Form von Feeds, sondern bringt auch erweiterte Funktionalitäten wie z. B. Upstream-Support für NuGet und npm mit. Upstream-Support ermöglicht das Zwischenspeichern von Packages in Azure DevOps, wenn der Entwickler das Paket das erste Mal abruft. Steht das Paket aus diversen Gründen nicht mehr zur Verfügung, kann der Entwickler aber über Build Agents beispielsweise auf die zwischengespeicherte Version zurückgreifen. Auch dies ist ein Bereich, in dem Microsoft sicherlich noch das ein oder andere Feature liefern wird.

Zuvor relativ beiläufig erwähnt, ist auch das Universal Package für viele Entwickler sehr spannend. Das Feature selbst ist eine Weiterentwicklung einer zuvor nur Microsoft-intern entwickelten Technologie. Universal Packages ermöglichen das generische, versionierte Speichern von Dateien im TFS. Das Besondere dabei ist die eingebaute Datenduplizierung bei Up- und Download, sodass gleiche Daten nicht mehrfach gespeichert oder abgerufen werden müssen. Durch diesen Ansatz sinkt das benötigte Speichervolumen für Build-Artefakte drastisch, während gleichzeitig die Performance steigt, da Teile der Daten oft schon auf lokalen PCs vorliegen.

Die Datenduplizierung selbst funktioniert momentan noch nur auf bestimmten Windows-Versionen; aber wenn sie unterstützt wird, dann werden die Inhalte bis auf die Blockebene genau mit dem jeweiligen Server abgeglichen. Hier kann man sicherlich auch davon ausgehen, dass es noch einige Neuerungen geben wird, weil wir uns noch eher am Anfang des Featurelebenszyklus befinden.

Fazit

Für die alten Hasen unter den Lesern – gemeint sind die Entwickler mit einer langen TFS- bzw. VSTS-Historie – mag sich die neue Namensgebung komisch anfühlen. Insbesondere wenn Microsoft Azure in der eigenen Entwicklung nicht die Zielplattform ist. Dennoch ist nachvollziehbar, wie sich Azure DevOps als starke Marke etablieren kann, die für Offenheit und eine Vielfalt an unterstützten Technologien steht. Diese Offenheit hat Microsoft durch den Zukauf von GitHub und die beibehaltene strikte Trennung zwischen den kommerziellen Produkten und dem Support der Open-Source-Community noch untermauert. Das kostenfreie Bereitstellen einer kompletten CI/CD Pipeline ist hier nur ein Beispiel.

Unterm Strich ist die aktuelle Weiterentwicklung von Microsofts Entwicklungsplattform also eine Win-win-Situation. Microsoft als Hersteller eröffnet sich Zugang zu einer größeren Community und arbeitet weiter am eigenen Image. Die Bestandskunden erhalten neue Features bzw. Vergünstigungen, wie bei den inkludierten Ausführungszeiten der CI/CD Pipeline zu sehen ist. Zu guter Letzt sei da noch die Open-Source-Community zu nennen, die von einem Weltkonzern mit vielen Möglichkeiten unterstützt wird.

In unseren industriellen Softwareentwicklungsprojekten nehmen wir diesen Wandel ebenfalls wahr. So ist der Einsatz von Azure-Cloud-Diensten eben auch bei einem mittelständischen Maschinen- oder Anlagenbauer kein Tabuthema mehr. Im Gegenteil, immer mehr unserer Projekte wickeln wir nicht mehr auf „alten“ TFS-Servern ab, sondern verwenden Azure DevOps mit den hier aufgezeigten Möglichkeiten und betreiben Test- und häufig auch Produktionsumgebungen auf der Microsoft-Azure-Plattform.

Microsofts Plan scheint also – zumindest in unserer Wahrnehmung – aufzugehen, und wir als Teil der Entwicklercommunity freuen uns über die vielen neuen Möglichkeiten.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -