Seite 2: Schwächen und Inkonsistenzen

Inhaltsverzeichnis

Die Dokumentation von Microsoft ist zu diesem Thema leider äußerst unvollständig. So findet man erst durch eigene Analyse der virtuellen Systeme über spezielle Test-Pipelines, die die Umgebungsvariablen und das Dateisystem auswerten sowie testweise Werkzeuge starten, heraus, dass auf den Agents auch ein .NET Core 2.1 SDK und verschiedene Java-Versionen (zwischen 7 und 11), teilweise auch Go, Python, PowerShell Core, Maven, Gradle, Android SDK und Chrome Web Driver für Selenium vorinstalliert sind.

Zudem ist die Konfiguration nicht durchgängig gleich: So gibt es PowerShell Core nur unter den macOS- und Ubuntu-Agenten. Der Task "PowerShell" bietet ein Häkchen "Use PowerShell Core", was zur Ausführung von pwsh.exe der PowerShell Core statt powershell.exe der Windows PowerShell führt. Der Task läuft damit aber dann nicht unter den Windows-Agenten, weil eben dort PowerShell Core nicht vorhanden ist. Immerhin laufen alle Builds auf den Microsoft-Agents unter administrativen Rechten, das heißt, Zusatzinstallationen sind möglich. Die Cloud liefert jedoch bei jedem Build-Durchlauf dafür eine frische virtuelle Maschine, Downloads aus dem Netz und Installationen ziehen demnach die Build-Laufzeiten in die Länge. Für die Installationen und Build-Ausgaben sind insgesamt 10 GByte Festplattenspeicher in den Agent-VMs verfügbar.

Alternativ kann man hier auch seine eigene virtuelle Maschine in der Azure-Cloud oder im eigenen Rechenzentrum bereitstellen. Das ist insbesondere geboten, wenn man die kostenfreie Version der Azure DevOps Services nutzt, bei der die Rechenzeit für alle Pipelines auf 1800 Minuten im Monat begrenzt ist (vgl. Teil 1 dieser Serie). Auf dem virtuellen System muss man dann die Agent-Software von Azure DevOps installieren (siehe Schaltfläche Download agent in Project Settings | Pipelines | Agent Pools) und die Firewall entsprechend konfigurieren.

Wenn man nach dem Anwenden der Vorlage keine grafische Darstellung des Ablaufs wie in Abbildung 1, sondern nur ein YAML-Listing wie im folgenden Listing sieht, dann hat man in den Benutzereinstellungen das Preview-Feature "New YAML pipeline creation experience" aktiviert.

# ASP.NET Core
# Build and test ASP.NET Core projects targeting .NET Core.
# Add steps that run tests, create a NuGet package, deploy, and more:
# https://docs.microsoft.com/azure/devops/pipelines/languages/dotnet-core

pool:
   vmImage: 'Ubuntu 16.04'

variables:
   buildConfiguration: 'Release'

steps:
- task: DotNetCoreCLI@2
   displayName: Restore
   inputs:
     command: restore

     projects: '$(Parameters.RestoreBuildProjects)'


- task: DotNetCoreCLI@2
   displayName: Build
   inputs:
     projects: '$(Parameters.RestoreBuildProjects)'

     arguments: '--configuration $(BuildConfiguration)'


- task: DotNetCoreCLI@2
   displayName: Test
   inputs:
      command: test

      projects: '$(Parameters.TestProjects)'

      arguments: '--configuration $(BuildConfiguration)'


- task: DotNetCoreCLI@2
   displayName: Publish
   inputs:
     command: publish

     publishWebProjects: True

     arguments: '--configuration $(BuildConfiguration) --output $(build.artifactstagingdirectory)'

     zipAfterPublish: True


- task: PublishBuildArtifacts@1
   displayName: 'Publish Artifact'
   inputs:
      PathtoPublish: '$(build.artifactstagingdirectory)'

Microsoft will es ermöglichen, dass man in Zukunft anstelle des Zusammenklickens auch die Schritte einer Build-Pipeline in YAML-Syntax erfassen kann. Leider ist es derzeit ein Entweder-oder: entweder klicken (Designer-Pipeline) oder YAML (YAML-Pipeline) tippen. Ein laufender Wechsel zwischen den Ansichten wie bei der Windows Presentation Foundation (WPF) zwischen XAML und Designer ist nicht möglich.

Nun können berechtigte Nutzer den Übersetzungsvorgang jederzeit manuell starten, indem sie auf Queue klicken. Im Sinne von Continuous Integration will man den Build aber jedes Mal starten, wenn neuer Quellcode in Azure DevOps eintrifft. Das stellt man unter "Triggers" bei dem Häkchen "Enable continuous integration" ein.

Unter Pipelines | Builds sehen die Nutzer die erstellte Build-Pipeline. Ein Klick auf die Pipeline führt zur Ansicht "History", in der sie Durchläufe der Pipeline und den Erfolg beobachten können. Bei einem einzelnen Build-Durchlauf erkennt man unter "Logs" die Details der Konsolenausgabe. Diese Ausgaben kann man auch bei einem laufenden Build-Vorgang im Browser mitverfolgen: Per Websocket-Verbindung wird der Browser vom Webserver auf dem aktuellen Stand gehalten (s. Abb. 2).

Es ist zu beobachten, dass Azure DevOps in der Log-Konsolenausgabe verschiedene Farben verwendet. Jedoch bieten eigene Werkzeuge und Skripte leider keine Farbausgaben. Eine Ausgabe in einem PowerShell-Skript-Task mit

Write-Host "Server nicht erreichbar" -ForegroundColor red

führt zu einem weißen statt rotem Text im Protokoll. Nur spezielle Ausgaben, die mit "##vso" eingeleitet werden, generieren farbige Ausgaben:

Write-Host "##vso[task.logissue type=warning;] Server nicht erreichbar"

Zur Erinnerung an den ersten Teil dieser Artikelserie: VSO steht für Visual Studio Online und war einer der vielen Vor-Vorgängernamen von Azure DevOps (vgl. Teil 1). Microsoft kommt von den alten Beziehungen an einigen Stellen nicht mehr los.