Continuous Delivery mit Azure DevOps, Teil 1: Projektinstallation

Inhaltsverzeichnis

In einer dreiteiligen Artikelserie stellt heise Developer das kontinuierliche Bauen und Ausliefern von Software mit Azure DevOps Services vor. Im ersten Teil geht es um das Einrichten eines DevOps-Projekts, des Weiteren um die Aufgabenverwaltung sowie die Quellcodeverwaltung mit Git und Team Foundation Version Control (TFVC).

Microsoft macht es weder Kunden noch Journalisten einfach, über die Redmonder Produkte im Bereich Continuous Integration und Continuous Delivery zu reden, da die Namen sich in den letzten 13 Jahren mehrfach geändert haben. Einen Quellcodeverwaltungsserver bietet Microsoft seit 1995 an: Visual SourceSafe wurde im Jahr zuvor durch die Übernahme der Firma One Tree Software erworben. Wegen seiner Schwächen im Bereich der Datenbankkonsistenz wurde er oft als "Quellcodevernichtungssystem" verspottet. Microsoft selbst hat für seine interne Softwareentwicklung SourceSafe kaum eingesetzt.

Mehr Infos

Continuous Delivery mit Azure DevOps – die Serie

• Teil 1: Projektinstallation
• Teil 2: Bauen auf dem Server
• Teil 3: Ausrollen per Geisterhand

Die Entwicklung von SourceSafe endete 2005. Im selben Jahr erschien die erste Version des Team Foundation Server (TFS), der mit Team Foundation Version Control (TFVC) nicht nur eine zuverlässigere Versionsverwaltung, sondern auch ein komplettes Serverprodukt für das Application Lifecycle Management (ALM) bot: Projektmanagement mit Projektplanung und Berichten, Aufgaben- und Bug-Tracking (Work Items), Dokumentenverwaltung sowie serverseitiges Übersetzen und Testen. Zusammen mit Visual Studio vermarktete Microsoft den TFS als Visual Studio Team System (VSTS).

Von TFS zu Azure DevOps

2008 stieg Microsoft beim Cloud Computing ein (damals noch Windows Azure genannt). Am 28. November 2010 kündigte der Hersteller auf der Professional Developers Conference an, auch einen TFS in der Cloud anzubieten. Der Name war damals Team Foundation Service (TF Service), teilweise sprach man von TFS Online. Es dauerte knapp ein Jahr bis zur ersten Vorschauversion und noch mal ein Jahr bis zur ersten stabilen Ausgabe.

Anschließend erfolgte eine Umbenennungsorgie: Seit dem 13. November 2013 heißt das Produkt Visual Studio Online (VSO), am 18. November 2015 griff Microsoft die mittlerweile in Vergessenheit geratene Bezeichnung VSTS wieder auf, dieses Mal als Abkürzung für Visual Studio Team Services und nur bezogen auf den TFS in der Cloud. Am 10. September 2018 wurde das Produkt nochmals umbenannt, jetzt in Azure DevOps Services.

Auch die nächste Version des Team Foundation Server ist davon betroffen. Einen TFS 2019 wird es nicht mehr geben, er heißt nun Azure DevOps Server 2019. Er trägt das "Azure" im Namen, obwohl er lokal ("On Premise") und gar nicht in der Cloud läuft. Ob das sinnvoll ist, wird sich zeigen. Sicherlich erlaubt die Namensgebung den Redmondern, den TFS zu den Cloud-Umsatzzahlen hinzuzurechnen. Aber mancher IT-Manager gerade im Cloud-scheuen Deutschland wird allein aufgrund des Namens den Einsatz des Produkts kategorisch ausschließen.

Aktueller in der Cloud

Ursprünglich war der TFS in der Cloud eine abgespeckte Variante des lokal installierbaren Team Foundation Server. Seit einigen Jahren hat sich das Bild umgekehrt: Der im Dreiwochenrhythmus aktualisierte Cloud-Dienst bietet mehr Funktionen, da das lokal installierbare Produkt nur vierteljährlich aktualisiert wird. Microsoft stellt daher neue Features in der Cloud eher zur Verfügung und manche Funktionen lokal gar nicht, zum Beispiel Integrationsfunktionen mit GitHub.

Dieser Beitrag orientiert sich an der in der Cloud als Azure DevOps Services verfügbaren Version vom 1. Oktober 2018. Mit einem lokal installierbaren TFS 2018 mit Update 3 sollten sich die vorgestellten Szenarien nachvollziehen lassen. Mittlerweile sind zwei weitere Sprints erschienen (Sprint-Updates 142, 143).

Kostenfrei für bis zu fünf Benutzer

Kosten müssen dabei keine entstehen. Microsoft bietet den Einsatz der Azure DevOps Services mit bis zu fünf Benutzern kostenfrei an. Die Anzahl der Projekte und der Speicherplatz sind unbegrenzt. Auf 1800 Minuten limitiert sind die Rechenzeiten für Build- und Release-Pipelines. Abbildung 1 zeigt den Preis für 20 Benutzer.

Open-Source-Projekte können seit kurzem mit unbegrenzter Benutzeranzahl bis zu zehn gleichzeitige Pipeline-Prozesse nutzen. Für den lokal installierbaren TFS gibt es ein anderes Preismodell. Doch auch hier gibt es eine kostenfreie, auf fünf Benutzer beschränkte Variante mit dem Namen TFS Express.

Ursprünglich wurde der Team Foundation Server direkt aus Visual Studio und Erweiterungen wie die TFS Power Tools gesteuert. Die Weboberfläche "TFS Web Access" war nur ein Nebenprodukt. Mittlerweile ist Letztere das Zentrum der Verwaltung von Azure DevOps, sowohl in der Cloud als auch bei der lokalen Installation.

Für die Nutzung der Azure DevOps Services benötigt man ein Microsoft-Konto, mit dem man sich anmelden kann. Nach dem Akzeptieren der Microsoft-Bedingungen gelangt man auf eine Seite, die einen auffordert, ein öffentliches oder privates Projekt anzulegen. In der linken Leiste ist zu sehen, dass bereits eine Organisation angelegt wurde, die so heißt wie der Name in der E-Mail-Adresse. Um den Namen der Organisation zu ändern, muss man unter "Organization Settings" (s. Abb. 2) die URL ändern. Die Azure-DevOps-URLs sind nach dem Prinzip https://dev.azure.com/OrganisationsName/Projektname aufgebaut, zum Beispiel https://dev.azure.com/HeiseDeveloper/MiracleList. Auf der nach dem Anlegen eines Projekts erscheinenden Startseite kann man per E-Mail weitere Personen in das Projekt einladen. Personen, die ein Visual-Studio-Abonnement unter der erfassten E-Mail-Adresse besitzen und die Einladung bestätigen, belasten nicht das kostenlose Kontingent von fünf Personen. Kunden, deren Entwickler Visual-Studio-Abonnements besitzen, können so Azure DevOps Services ohne Zusatzkosten verwenden.

In der Organisationsverwaltung können Projektadministratoren kostenfreie und kostenpflichtige Erweiterungen aus dem Azure-DevOps-Store in die eigene Organisation laden. Während viele der im App Store angebotenen Erweiterungen die Azure-DevOps-Weboberfläche verändern, findet man dort auch Werkzeuge, die lokal auf dem eigenen PC zu installieren sind, zum Beispiel ein Kommandozeilenwerkzeug, das noch "VSTS CLI" heißt. Auch per REST-API lässt sich Azure DevOps fernsteuern.

Neue Weboberfläche

Wer auf der Startseite ein Projekt anlegt, hat derzeit weder Einfluss auf die Projektmanagementmethode noch das Quellcodeverwaltungssystem. Man erhält automatisch ein "agiles" Projekt mit Git als Quellcodeverwaltung. Wer hingegen unter Organization Settings | Projects die Funktion New team project (s. Abb. 2) wählt, erhält wie bisher die Auswahl zwischen drei Projektmanagementmethoden (CMMI, Scrum und Agile, zu den Unterschieden s. Abb. 3) und zwei Quellcodeverwaltungssystemen (Team Foundation Version Control und Git). Da Team Foundation Version Control nicht mehr weiterentwickelt wird, ist Git zu bevorzugen. Microsoft zieht mit seinen eigenen Projekten zu Git um.

Die Projektmanagementmethoden haben Einfluss auf die Benennung und Funktionen der Aufgabenverwaltung (Azure Boards). Abbildung 3 zeigt die wichtigsten Unterschiede. Weitere Änderungen betreffen die Benennung der Arbeitsintervalle: Bei CMMI und Agile spricht Microsoft von "Iteration", bei Scrum wie üblich von "Sprint". Man kann für sein Projekt von einer der Projektmanagementmethoden erben (s. "Angepasster Scrum-Prozess" rechts unten in Abb. 2) und dann Einfluss auf die Aufgabenelementtypen (Work Item Type, WIT), deren Eigenschaften und Zustände nehmen.

Nach dem Anlegen des Projekts präsentiert sich die neu gestaltete Hauptansicht (s. Abb. 4) mit einer einklappbaren Menüleiste links, die die Azure DevOps-Dienste zeigt:

• Boards: Aufgaben- und Bugverwaltung
• Repos: Quellcodeverwaltung
• Pipelines: Build- und Release-Pipelines
• Test Plans: Testpläne
• Artifacts: Bereitstellung von Softwarepaketen (npm, NuGet, Maven)

Wer ein VSTS-Projekt vor dem Stichtag 10. September 2018 besaß, landet noch in der alten Weboberfläche mit dem Menü oben auf der Seite. Hier kann man in den Benutzereinstellungen unter Preview Features den Schalter New Navigation aktivieren. Zwei zentrale Schwächen der alten Oberfläche hat Microsoft in der neuen nicht beseitigt: Es ist kein Responsive Web Design, die Anwendung lässt sich also auf kleinen Bildschirmen nur schwer bedienen. An einigen Stellen erscheinen neu angelegte Elemente nicht automatisch in der Liste, sondern erst nach einem Mausklick auf die Refresh-Schaltfläche direkt über der Liste. Das gilt zum Beispiel für Project Settings | Security beim Hinzufügen von Mitgliedern zu einer Sicherheitsgruppe.

Viele Optionen bei der Aufgabenverwaltung

Im Bereich "Boards" gibt es mehrere Ansichten. "Work Items" bietet eine Listenansicht aller Work-Item-Typen. Für Einsteiger ist es irritierend, dass gerade erfasste Elemente nur in der Liste erscheinen, wenn man eine Benutzerzuordnung zu sich selbst vorgenommen hat. Sie ist aber optional, sodass diese Eigenschaft oft erst mal nicht gesetzt wird. Diese Elemente erscheinen dann nicht in der Work-Item-Liste, weil dort standardmäßig die Ansicht "Assigned to me" aktiv ist. Erst "My activity" zeigt alle Elemente, die man selbst erfasst hat, unabhängig von der Zuweisung.

Der zweite Eintrag unterhalb von "Boards" heißt dann wieder "Boards", in denen sich die Aufgaben in Kartendarstellung bearbeiten lassen (s. Abb. 4). Die Namensgebung "Boards" auch als übergeordneten Begriff zu verwenden, ist unglücklich. In diesem Board im Kanban-Stil können Nutzer die Elemente per Drag&Drop in einen anderen Status verschieben (s. Element Kategorien löschen in Abb. 4). Mit sogenannten Swimlanes kann man für bessere Ordnung sorgen (s. Swimlanes "Eilbedürftig" und "Standard" in Abb. 4). Unter Boards | Sprints | Taskboard versteckt sich eine weitere Form von Drag&Drop-Board in Azure DevOps. Hier verschiebt man Task-Elemente, die Unterelemente von Backlog Items sind (s. Abb. 5).

Die Backlog-Ansicht zeigt eine Liste der Elemente, wahlweise als Hierarchie.

Eine Zuordnung zwischen Elementen, zum Beispiel Epic und Feature, erfolgt, indem man ein neues Element direkt als Unterelement anlegt (mit dem Pluszeichen vor dem Element) oder nachträglich Change Parent wählt. Mit View as board und View as backlog können Nutzer zwischen Board- und Backlog-Ansicht wechseln. Eine weitere Backlog-Ansicht finden sie unter caps]Sprints | Backlog[/caps]; hier sieht man nur die Backlog Items und Bugs des gewählten Sprints.

In den Ansichtseinstellungen für Board und Backlog kann man zunächst nur zwischen Features und Backlog Items wählen. Um auch die Epic-Elemente zu sehen, muss man im Einstellungsrad unter General | Backlogs das Häkchen "Epics" aktivieren. Optional gibt es eine vierte Backlog-Ebene: das Portfolio, das Nutzer aber durch Anpassungen erst mühsam aktivieren müssen.

Mit zwei Boards (Kanban und Task) sowie drei Backlog-Ansichten (inkl. Portfolio) kommen Anwender demnach auf fünf Aufgabenansichten. Microsoft bietet eine Tabelle, die Aufschluss gibt, welche Funktionen in welcher der Ansichten verfügbar sind.

In den Projekteinstellungen können Anwender unter Working with Bugs festlegen, ob sie Bugs als "Requirements" oder als "Tasks" verwalten – oder gar keine explizite Fehlerverwaltung wollen. Die Sprints und deren Terminierung legen sie in den Projekteigenschaften fest. Auch eine Trennung in verschiedene Teams ist möglich, wobei jedes Team seine eigenen Boards und Listen bekommt. Den teamübergreifenden Überblick behalten Anwender, in dem sie sich ihr eigenes Dashboard (im Menü Overview) zusammenklicken (s. Abb. 7).

Quellcodeverwaltung

Anders als das Projektmanagementsystem kann man das Quellcodeverwaltungssystem später noch ändern. In den Projekteigenschaften unter Code | Repositories können Projektadministratoren für ein Projekt mehrere Repositories anlegen und dabei zwischen Git und Team Foundation Version Control (TFVC) wählen. Allerdings darf maximal ein TFVC-Repository pro Azure-DevOps-Projekt existieren, während es hier mehrere Git-Repositories geben kann.

In der "Repos"-Ansicht schalten Anwender im Drop-Down-Menü zwischen den Repositories um. Bei einem leeren Git-Repository finden sie in der "Files"-Ansicht die Möglichkeit, das Git-Repository zu initialisieren. In ihr kann man dann im Webbrowser Dateien anlegen und bearbeiten – sogar mit Syntaxfarbhervorhebung und IntelliSence-Eingabeunterstützung (s. Abb. 8).

Wer die "Command Palette" aus dem Kontextmenü aufruft, fühlt sich wie in Visual Studio Code. Tatsächlich wirkt hier das Erich-Gamma-Projekt "Monaco", das auch die Basis für Visual Studio Code bildet.

Entwickler können Ordner auch direkt im Browser erschaffen, allerdings erst seit TFS 2018. Vorher wurde dafür eine Erweiterung benötigt. Hilfreich ist die kostenfreie Erweiterung Code Search, die das Kontextmenü ergänzt.

Die URL zum Klonen des Repositories findet man hinter der Schaltfläche Clone, zum Beispiel für das oben angelegte Projekt:

git clone https://HeiseDeveloper@dev.azure.com/HeiseDeveloper/MiracleList/_git/MiracleList 

Bei Clone gibt es die Möglichkeit, ein Repository mit einem Editor wie WebStorm, PhpStorm, Visual Studio, Visual Studio Code, Android Studio oder Eclipse (um nur eine Auswahl zu nennen) zu klonen. Er muss vorher auf dem Entwicklungssystem des Nutzers installiert worden sein. Mit der Git-URL können Entwickler den Klonvorgang auch im Werkzeug ihrer Wahl starten.

In Visual Studio ist zu beachten, dass man erst einmal in den Einstellungen der IDE das Standardquellcodeverwaltungssystem von TFVC auf Git ändern muss. Danach kann man sich über den Team Explorer mit dem Projekt in Azure DevOps verbinden und das Git-Repository klonen (s. Abb. 9).

In der Folge senden Entwickler über die "Changes"-Ansicht des Team Explorer Änderungen zu Azure DevOps. Nicht verfügbar für solch ein Git-Repository in Visual Studio ist allerdings der "Source Control Explorer": Er funktioniert nur für TFVC-Repositories.

Mehr Infos

Das Cross-Plattform-Fallbeispiel war Gegenstand einer Artikelserie in den iX-Ausgaben 5/2017, 6/2017, 7/2017 sowie 2/2018 und 3/2018.

Nun sei ein Zeitsprung vollzogen: Alle eingestellten Aufgaben sind bereits erledigt, der Quellcode ist fertig erstellt. In Hinblick auf den zweiten Teil der Artikelserie wird nun der Quellcode des .NET-Core-Projekts Miracle List-Backend und des Cross-Plattform-Projekts Miracle List-Client mit HTML, TypeScript, Angular, Electron und Cordova in zwei Git-Repositories in das Azure-DevOps-Projekt eingespielt.

Im wahren Leben wäre der Quellcode häppchenweise entstanden und serverseitige Build- und Release-Pipelines hätten das kontinuierlich unterstützt. Hier soll der Quellcodestand aus der iX-Artikelserie die Basis für die Einrichtung dieser Pipelines in den kommenden beiden Teilen der Artikelserie auf heise Developer sein.

Fazit

Der erste Teil der Serie hat die Grundlagen für die Projekt- und Quellcodeverwaltung in Azure DevOps gelegt. Die Quellcodeverwaltung bietet mit dem verteilten Git und zentralen Team Foundation Version Control zwei verschiedene Quellcodeverwaltungssysteme an – je nach Geschmack des Entwicklungsteams. Auch die Aufgabenverwaltung ist flexibel, allerdings in einigen Punkten sehr unübersichtlich. Hier besteht Optimierungsbedarf bei Benennung und Navigation. Im zweiten Teil geht es darum, für die beiden Projekte eine Build-Pipeline inklusive Unit Tests einzurichten.

Dr. Holger Schwichtenberg
leitet das Expertennetzwerk www.IT-Visions.de, das Beratung, Schulungen und Softwareentwicklung im Umfeld von Microsoft-, Java- und Web-Techniken anbietet. Er selbst schreibt Software in C# und JavaScript/TypeScript, hält Vorträge auf Fachkonferenzen und ist Autor zahlreicher Fachbücher. (ane)