In der modernen Software-Entwicklung gehören Build-Pipelines zum allgemeinen Standard. Neben automatisierten Builds sowie Tests stellen Build-Pipelines reproduzierbare Builds sicher. Über zentrale Codestände wird verhindert, dass lokale Änderungen die Qualität verfälschen.

Da die Entwicklung von Unity-XR-Applikation oft direkt im Zusammenspiel mit einem entsprechenden Device erfolgen, tendieren viele Entwickler dazu, doch auf den schnellen lokalen Build zu setzen, was ein zusätzliches Risiko bringt.

Für den Einstieg in die Thematik haben mein ehemaliger Kollege Kai Nottrodt und ich unsere Erfahrungen hier zusammengetragen.

Herausforderung

Im Rahmen der Unity-Entwicklung werden 3D-Modelle mit der entsprechenden Anwendungslogik kombiniert. Im folgenden Schritt wird daraus dann ein Build für das entsprechende Device kompiliert. Der eingebundene lokale Compiler nutzt hierbei als Standard-Parameter u.a. die Vorgaben des CPUs des Entwickler-PCs.

Somit können auch bei neu gezogenen Codeständen auf zwei unterschiedlichen PCs unterschiedliche Builds herauskommen, die z.B. das Laufzeitverhalten der Applikation beeinflussen können. Solche Abweichungen müssen vermieden werden, um Eindeutigkeit und Nachvollziehbarkeit im Buildprozess sicherzustellen.

Ablauf

Der Build-Prozess definiert mehrere einzelne Schritte, die durch eine entsprechende Trennung ohne Seiteneffekte durchlaufen werden können. Durch die Aneinanderreihung dieser Schritte auf einem Buildserver zu einer Build-Pipeline wird die Unabhängigkeit sichergestellt, die dann auch als Basis für integrative Tests genutzt werden kann. Zudem blockiert ein zentraler Build den Entwicklungsrechner nicht.

Lösung

Im folgenden Beispiel eines Entwicklungsprojekt für HoloLens ist zu erkennen, welche Schritte in einer Build-Pipeline in Azure DevOps benötigt werden, um einen reproduzierbaren Build sicherzustellen.

Quelle: Accenture

Wie in der Darstellung zu sehen ist, besteht die Pipeline aus 4 Schritten:

  1. Start des Buildservers
  2. Unity Build
  3. Visual Studio Build
  4. Herunterfahren des Buildservers

Zur Realisierung wird der Service Azure DevOps benutzt. Der Service bietet ein Tool für den Zusammenbau von Pipelines mit einer hohen Anzahl von verfügbaren Plugins.

Unity-Tools for Azure-DevOps bietet einem den Zugriff zur den Unity Command Line Tools. Azure Virtual Machine Manager steuert Azure Machines und wird benötigt, wenn ein eigener Buildserver verwenden soll. Dies ist empfehlenswert, da sonst Unity auf den Standard Buildserver immer neuinstalliert werden müssen.

Der Check Out des Projekts läuft direkt über die Azure DevOps Pipeline und ist mit einer simplen Authentifizierung erledigt.

Für die Durchführung der Builds sind die Plugins Unity-Tools für Azure-DevOps und Visual Studio zuständig. Grundsätzlich werden hier nur die Buildschritte nachgebaut und in Unity einen UWP Build erstellt und anschließend in Visual Studio für die Hololens ein ARM Appx Bunde umgesetzt.

Wichtig ist zu wissen, dass in für den Unity Build folgende Build-Methode gesetzt werden muss:  

Microsoft.MixedReality.Toolkit.Build.Editor.UnityPlayerBuildTools.StartCommandLineBuild

Es wird empfohlen, für eine Erhöhung der Testqualität hier auch Unit Tests einzubinden.

Nach dem Erstellen der AppPackages sollte dies für die weitere Verwendung entsprechend abgelegt werden. Eine einfache Variante ist z.B. einen Shared Folder hierfür zu verwenden.

Ausblick

Mit dem so sichergestelltem Build können dann die weiteren Prozess-Schritt durchlaufen werden, um eine hohe Qualität der zu entwickelnden Applikation sicherzustellen. Aufgrund der Abhängigkeit zu den Devices und den daraus entstehenden Limitierungen in der Strategie zu Integrationstests und End-to-End-Testing, bringen ein vollständige CI/CD-Pipeline noch weitere Herausforderungen. Momentan bietet Microsoft noch keine Lösung für ein Auto Deployment, aber ein Ansatz über ein Azure Blob Storage ist in Entwicklung.

Klaus Stammermann

Senior Technology Architect

ABONNEMENT-CENTER
Melden Sie sich bei unserem Accenture's IES ASG Newsletter an! Melden Sie sich bei unserem Accenture's IES ASG Newsletter an!