Willkommen im Zeitalter der beschleunigten Softwareentwicklung, wo die Zeit so kostbar ist, dass selbst Koffein manchmal nicht schnell genug wirkt! Heute tauchen wir ein in Azure Pipelines, diese können langsam sein und damit stören – insbesondere, wenn man seine Änderungen kontinuierlich deployen und nur kurz den Status überprüfen möchte. Durch Parallelisierung haben wir die Laufzeit einer Azure Pipeline verkürzen und den Störfaktor somit gesenkt. In diesem Blogbeitrag möchten wir unsere Erkenntnisse und Erfahrungen teilen.
Parallelisierung in Azure DevOps Pipelines
Azure DevOps Pipelines sind von Haus aus in der Lage Jobs zu parallelisieren . Dabei erfordert jeder parallele Job einen separaten Agenten. Für private Projekte können ggf. zusätzliche Kosten entstehen (entweder zwei MS-hosted Pipelines oder eine weitere self-hosted Pipeline), weitere Infos dazu finden sich hier.
Wir betreiben derzeit zwei Agenten auf einem Rechner. Diese Agenten teilen sich vier Prozessoren. Die Auslastung der Rechner haben wir zu verschiedenen Zeitpunkten genauer betrachtet. Dabei sind uns gelegentliche Leistungseinbrüche aufgefallen, wenn zwei ressourcenintensive Tasks gleichzeitig ausgeführt werden. Aus diesem Grund raten wir dazu, bei jeglichen Pipelines die verfügbaren Ressourcen im Auge zu behalten, um noch Luft nach oben zu haben.
Aufteilung der Jobs – aber wie?
Wie kann nun eine sinnvolle Aufteilung der Jobs aussehen? Für unsere Webapplikation mit Angular im Frontend und .NET im Backend hatten wir folgenden Build-Job:
Die neue Aufteilung ermöglicht eine schnellere Ausführung, da nun zwei Jobs parallel laufen können, statt bislang nur einem Job, der sequenziell ablief.
Ein zusätzlicher Vorteil: bei fehlerhaften Durchläufen muss nur der fehlerhafte Job erneut durchlaufen. Außerdem erleichtert die Aufteilung der Jobs die Identifizierung von Engpässen, da nun die Ausführungsdauer der einzelnen Jobs eingesehen werden kann – ansonsten kann lediglich die gesamte Ausführungsdauer gemeinsam betrachtet werden.
Um diesen Job zu verbessern, haben wir uns einige Gedanken gemacht und wollten zuerst front- und backend Build und das Testing voneinander trennen. Die Zeitersparnis wäre an dieser Stelle jedoch sehr gering ausgefallen, daher haben wir uns dafür entschieden den gesamten Build-Job in Backend und Frontend aufzuteilen:
Ergebnisse
Ohne Parallelisierung dauerte ein Durchlauf ursprünglich ca. 14 Minuten. Durch die Job-Parallelisierung ist dieser Prozess auf solide 11 Minuten reduziert.
Unser Backend-Job braucht 6 min womit wir nach der Zeit einen freien Agenten haben welcher sich um andere Themen kümmern kann. In der Theorie sparen wir außerdem 6 min pro Durchlauf. Leider sind unsere VM’s ausgelastet wenn die Pipeline durchläuft, weswegen die gleichzeitige Ausführung beider Jobs bei uns nicht ihre volle Wirkung zeigt und wir pro Durchlauf ca. 3-4 min sparen. Eine bessere Leistung der VM’s würde eine höhere Beschleunigung bewirken.
Es gibt zahlreiche Projekte, die von dieser Zeit profitieren können. Das ist vor allem dann der Fall, wenn mehrere Build-Phasen verwendet werden. In solchen Fällen hilft die Parallelisierung dadurch, dass bereits ein Job seine Artefakte published, während der andere Vorbereitungen ausführt. Das führt dann zu einer deutlich spürbaren und wichtigen Beschleunigung.
Je nach Projekt kann der Aufwand variieren – in unserem Beispiel konnte die Grund-Umsetzung innerhalb von Stunden durchgeführt werden. Solche Änderungen können aber auch deutlich mehr Zeit in Anspruch nehmen. Ob der investierte Zeitaufwand betrieben werden soll, ist eine projektindividuelle Entscheidung.
Fazit
Die Einführung von Parallelisierung in Azure CI/CD-Pipeline führt zu einer soliden oder auch deutlich wichtigen Beschleunigung. Trotz der gewonnenen Effizienz ist dies keine Universallösung für jede CI/CD-Pipeline. Unsere Erfahrungen sollen vielmehr als Anregung dienen, die Möglichkeiten der Azure Pipelines voll auszuschöpfen und dabei spezifische Anforderungen im Blick zu behalten. Von einer kurzen Analyse und einem Hinterfragen der aktuellen Build-Laufzeiten sollten Sie jedoch nicht zurückschrecken. Es kann sich lohnen und Ihre Entwickler danken es Ihnen!
Danke fürs Beitragsbild an Freepik