Continuous Delivery mit Azure DevOps, Teil 2: Bauen auf dem Server

Im zweiten Teil der dreiteiligen Artikelserie geht es um das Einrichten eines Server-Builds in Azure DevOps Services und Team Foundation Server (TFS) für eine .NET Core- und eine Angular-Anwendung.

Werkzeuge  –  2 Kommentare
Continuous Delivery mit Azure DevOps, Teil 2: Bauen auf dem Server

Kurz zur Rekapitulation: Im ersten Teil wurde ein Projekt in Azure DevOps Services mit zwei Git-basierten Quellcode-Repositories eingerichtet. Neben den Aufgaben wurde bereits Quellcode für ein ASP.NET-Core-Serverprojekt (Miracle List-Backend) und ein Angular-Client-Projekt (Miracle List-Client) in die Cloud gebracht, der sich jeweils lokal auf dem Entwicklersystem übersetzen und auch einwandfrei testen ließ.

Sich zufrieden zu geben mit "es läuft doch auf meinem Rechner" gehört sicherlich zu den häufigsten Fehlerquellen in der Softwareentwicklung. Es gilt nämlich zu beweisen, dass sich wirklich alle benötigten Dateien im Quellcodeverwaltungssystem befinden und auch ein "nacktes" System die Projekte übersetzen und validieren kann.

Continuous Delivery mit Azure DevOps – die Serie

Im neuen Azure-DevOps-Portal steht eine Rakete als Symbol für die "Azure Pipelines". In dem Menüpunkt gibt es dann die Unterscheidung in "Build" und "Release". Ein Build übersetzt das Projekt und startet Unit-Tests zur Überprüfung, üblicherweise aber keine Integrationstests, die Prozesse und Ressourcen wie Webserver oder Datenbankserver erfordern. Solche Integrationstests sind in der Release-Pipeline vorgesehen, die erst angestoßen wird, wenn der Build und die Unit-Tests erfolgreich waren.

Beide Pipeline-Arten bestehen aus einzelnen Schritten, die jeweils zu einer Task-Art gehören. Die Benutzeroberfläche für Build- und Release-Pipelines ist ähnlich, aber dennoch gibt es Unterschiede. Die Build-Prozesse gibt es im Team Foundation Server seit der ersten Version im Jahr 2005. Die ursprünglich XAML-basierte Build-Definition hat Microsoft 2015 durch ein neues System abgelöst, das intern auf JSON-Dokumenten basiert. Die Release-Pipelines stammen hingegen aus dem Aufkauf des Werkzeugs InRelease der Firma InCycle 2013.

Build für ASP.NET Core anlegen

Der einfachste Weg zu einem Build-Prozess führt über die Schaltfläche Set up build, die in der Quellcodeverwaltung (Menü Repos | Files) angeboten wird. Damit ist der Bezug zum richtigen Quellcode-Repository schon geklärt. (Zur Erinnerung: Es kann in einem Azure-DevOps-Projekt ein TFVC-Repository und beliebig viele Git-Repositories geben.) Entwickler können nun aus rund 20 Vorlagen für einen Build-Prozess auswählen. Es gibt nicht nur Vorlagen für typische Projektarten der .NET-Welt (.NET Desktop, ASP.NET, ASP.NET Core, Xamarin, UWP), sondern auch für Java mit Maven oder Ant, Node.js, Objective-C mit Xcode, Go und Python.

Für das mit ASP.NET Core erstellte "Miracle List"-Backend wählt man am besten die Vorlage "ASP.NET Core". Hier ist zu beachten, dass es auch noch eine Vorlage "ASP.NET Core (.NET Framework)" gibt, die sich aber nur eignet, wenn ASP.NET Core auf dem klassischen .NET Framework laufen soll. Für eine echte Cross-Plattform-Serveranwendung muss ASP.NET Core auf .NET Core laufen, und das erreicht man mit der Vorlage "ASP.NET Core" ohne weiteren Namenszusatz. Das Ergebnis der Anwendung dieser Vorlage zeigt Abbildung 1.

Mit der Vorlage "ASP.NET Core" angelegte Build-Pipeline (Abb. 1)

Das Webportal hat eine Build-Pipeline mit sechs Schritten geschaffen:

  1. Abholen des Quellcodes aus dem Git-Repository.
  2. Laden der benötigten NuGet-Pakete, was notwendig ist, da es sich um ein mehr oder weniger "nacktes" Build-System handelt. Es ist sicherzustellen, dass alle benötigten NuGet-Pakete in der richtigen Version vorliegen.
  3. Dann erfolgt die Übersetzung mit dem Kommandozeilenwerkzeug dotnet build.
  4. Im vierten Schritt werden die Unit-Tests ausgeführt. Standard ist, dass alle Projekte, die im Ordner /Tests liegen, als Unit-Test-Projekte betrachtet werden. Dafür steht in der Eigenschaft "Path to project(s)" der Wert "**/*[Tt]ests/*.csproj".
  5. Anschließend wird das Ergebnis mit dotnet publish in eine verteilbare Form gebracht (hier werden alle nicht benötigten DLLs und andere unnötige Dateien aussortiert). Dabei ist die Option "Zip Published Projects" aktiv, da eine Veröffentlichung als Zip-Paket in Azure DevOps üblich ist.
  6. Schließlich wird mit dem Task "Publish Artifact" das Zip-Ergebnis in ein Ausgabeverzeichnis gepackt, auf das dann eine folgende Release-Pipeline zugreifen kann.

Welches Betriebssystem diese Build-Schritte ausführt, stellen Nutzer bei "Agent Pool" ein. Microsoft bietet vorgefertigte virtuelle Systeme als Build-Agents in seiner Azure-Cloud an:

  • Unter "Hosted" (ohne Zusatz) verbirgt sich ein Windows Server 2012 R2 mit Visual Studio 2012.
  • "Hosted VS2017" ist ein Windows Server 2016 mit Visual Studio 2017.
  • "Hosted macOS" bietet macOS 10.13 mit Xcode 8, 9 und 10.
  • "Ubuntu 16.04" bietet .NET Core SDK.
  • "Hosted Linux Preview" ist veraltet und wurde im Dezember 2018 eingestellt.