Continuous Delivery mit Azure DevOps, Teil 1: Projektinstallation
Seite 4: 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.
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)
