Zusammenfassung

Abgeschlossen

In diesem Modul richten Sie einen eigenen privaten Build-Agent ein, indem Sie einen unter Microsoft Azure ausgeführten virtuellen Computer verwenden.

Ein von Microsoft gehosteter Agent verfügt zwar oft über alles, was Sie benötigen, aber es gibt Situationen, in denen Sie möglicherweise die Verwendung ihres eigenen Build-Agent in Betracht ziehen.

Sie sollten einige Faktoren berücksichtigen, wenn Sie beschließen, einen von Microsoft gehosteten Agent anstelle eines eigenen Agents zu verwenden. Zu diesen Faktoren gehören folgende: wie viel Computeleistung und Speicherplatz erforderlich ist und wie viel Zeit für die Durchführung der Builds benötigt wird.

Wenn Sie einen privaten Build-Agent konfigurieren, können Sie diesen beliebig nach den eigenen Wünschen konfigurieren. Der Nachteil besteht darin, dass Sie Ihr System auch selbst mit den neuesten Sicherheitspatches und Buildtools aktualisieren müssen.

Das Tailspin-Webteam hat sein Experiment mit privaten Build-Agents abgeschlossen. Schauen wir uns ihre Ergebnisse an.

Tim: Mara und ich konnte einen Build-Agent auf einem virtuellen Azure-Computer ausführen. Der Build wird schnell ausgeführt, und wir erhalten die gleichen Ergebnisse wie bei der Verwendung eines von Microsoft gehosteten Agents. Aber bringt ein privater Build-Agent Vorteile für dieses Projekt?

Andy: Ich stimme zu, dass es ein gutes Experiment war. Aber vorerst sehe ich keinen Vorteil in der Verwendung unseres eigenen Agents. Die von Microsoft gehosteten Agents scheinen alles zu tun, was wir jetzt benötigen, und wir müssen uns nicht darum kümmern, Sie auf dem neuesten Stand zu halten. Wenn wir jedoch feststellen, dass wir mehr Buildzeit, Speicher oder Arbeitsspeicher benötigen, ist es gut zu wissen, dass wir die Möglichkeit haben, unseren eigenen Build-Agent zu verwenden.

Tim: Ich könnte mir vorstellen, dass einige der anderen Teams davon profitieren, insbesondere die Teams, die Spiele entwickeln. Ich weiß, dass einige Spiele mehrere Stunden zum Durchführen eines vollständigen Builds benötigen. Die Verarbeitung all dieser Spieleobjekte erfordert auch viel CPU, Arbeitsspeicher und Speicherplatz auf dem Datenträger.

Mara: Gutes Argument, Tim. Da wir diese Buildkonfiguration auf einem git-Branch eingerichtet haben, sind diese Änderungen von den Hauptquellen isoliert. Wir können den Build-Agent etwas länger ausführen, um ihn den anderen Teams zu demonstrieren.

Tim: Das klingt gut. Vielen Dank für Ihre Hilfe. Es war alles relativ einfach einzurichten. Und jetzt weiß ich etwas mehr darüber, wie virtuelle Computer in Azure funktionieren.

Wie schneidet das Team ab?

Im Modul Bewerten des vorhandenes Softwareentwicklungsprozesses hat Mara eine Übung zur Wertstromzuordnung durchgeführt, um dem Team zu helfen, den aktuellen Prozess für den Veröffentlichungszyklus zu analysieren.

Denken Sie daran, dass das Aktivitätsverhältnis bzw. die Effizienz als Verarbeitungszeit, geteilt durch die gesamte Vorlaufzeit definiert ist.

$${Aktivitätsverhältnis\ =\ }{\dfrac{Verarbeitungszeit}{gesamte\ Vorlaufzeit}}$$

Das Tailspin-Webteam hat festgestellt, dass die Effizienz nach dieser Metrik anfänglich bei 23 Prozent lag.

Obwohl das Team noch nicht zu einem vollständigen Lieferzyklus unter Verwendung von DevOps-Prozessen übergegangen ist, hat es bereits einige Ineffizienzen reduziert.

Bisher hat das Team Folgendes reduziert:

  • Die für die Einrichtung der Quellcodeverwaltung für neue Features erforderliche Zeit von drei Tagen auf null Tage.

    Sie taten dies, indem sie von einer zentralisierten Quellcodeverwaltung zu Git, einer Form der verteilten Quellcodeverwaltung, wechselten. Bei der verteilten Quellcodeverwaltung müssen sie nicht warten, bis Dateien entsperrt werden.

  • Die benötigte Zeit bis zur Übergabe von Code die Testerin Amita von zwei Tagen auf null Tage.

    Sie taten dies, indem sie ihren Buildprozess auf Azure Pipelines verlagerten. Azure Pipelines benachrichtigt Amita automatisch, wenn ein Build verfügbar ist, sodass die Entwickler Amitas Arbeitsblatt nicht mehr aktualisieren müssen.

  • Die von Amita zum Testen neuer Features benötigte Zeit von drei Tagen auf einen Tag.

    Dazu haben sie einen Komponententest ihres Codes durchgeführt. Da Komponententests jedes Mal ausgeführt werden, wenn eine Änderung die Buildpipeline durchläuft, kommen bei Amita weniger Fehler und Regressionen an, sodass sie die einzelnen manuellen Testdurchläufe wesentlich schneller abschließen kann.

Diese Änderungen verringern die gesamte Vorlaufzeit von 22 Tagen auf 15 Tage. Ersetzen Sie diese Zahlen in der Gleichung, und Sie erhalten Folgendes:

$${Aktvitätsverhältnis = }{\dfrac{5\ Tage}{15\ Tage}}{ = 0,33}$$

Wenn wir das Ergebnis mit 100 multiplizieren, erhalten wir eine Effizienz von 33 %.

Obwohl immer Raum für Verbesserungen vorhanden ist, ist dies eine sehr positive Änderung für das Team. Kunden erhalten den Wert nicht nur schneller, das Tailspin-Team verbringt jetzt weniger Zeit mit dem Warten und mehr Zeit mit dem, was Sie am meisten genießen: Features entwickeln, die ihre Kunden lieben werden.

Langsam wird auch die Verwaltung davon aufmerksam. Das Team plant, seinen geheimen Schlüssel mit der Verwaltung zu teilen, nachdem es noch etwas mehr Zeit hatte nachzuweisen, dass der Vorgang funktioniert.

Zusammenfassung des Lernpfads

Herzlichen Glückwunsch. Sie haben das letzte Modul im Lernpfad Erstellen von Anwendungen mit Azure DevOps abgeschlossen. In diesem Lernpfad haben Sie viel erreicht, einschließlich:

  • Einrichten eines Projekts in Azure Pipelines und Veröffentlichen von Buildartefakten in der Pipeline.
  • Implementieren eines Codeworkflows für Teammitglieder, die Git und GitHub verwenden.
  • Ausführen automatisierter Tests, z. B. Komponenten- und Code Coverage-Tests, wenn die Pipeline ausgeführt wird.
  • Verwalten Ihrer eigenen Pakete in der Pipeline und Verbinden der Pakete mit Ihren Anwendungen.
  • Verwenden Ihres eigenen Build-Agents, wenn von Microsoft gehostete Agents nicht Ihren Anforderungen entsprechen.

Der Schwerpunkt dieses Lernpfads liegt auf der Erstellung von Anwendungen und dem Empfang von Build-Artefakten, die Sie an Ihre QA-Teams oder IT-Betriebsabteilung weitergeben können.

Nächste Schritte

Sie und das Team haben einen großen Fortschritt gemacht, aber das große Release steht bevor. Wie wird das Team seine Buildartefakte in Entwicklungs-, Test- und Stagingumgebungen bereitstellen, um weitere Tests ausführen und ihre Arbeit überprüfen zu können? Wenn Sie mit dem Team zusammenarbeiten und erfahren möchten, wie Sie Releasepipelines erstellt werden, mit denen Ihre Anwendungen fortlaufend erstellt, getestet und bereitgestellt werden, wechseln Sie zu Bereitstellen von Anwendungen mit Azure DevOps.

Weitere interaktive Module zum eigenverantwortlichen Lernen rund um Azure DevOps finden Sie unter Azure DevOps Labs.

Weitere Informationen

Weitere Informationen zu Build-Agents und Agentpools finden Sie in den folgenden Artikeln:

Erstellen eigener VM-Images

Wenn Sie Ihre eigenen VM-Images für die Verwendung mit Azure Pipelines erstellen möchten, sehen Sie sich das Projekt azure-pipelines-image-generation auf GitHub an.

Üben der Ausführung virtueller Computer in Azure

Weitere praktische Übungen zur Arbeit mit virtuellen Computern in Azure finden Sie im Lernpfad Verwalten von Infrastrukturressourcen in Azure.

Wir haben auch erläutert, wie Sie Bicep verwenden können, um den Prozess der Erstellung von Build-Agents zu automatisieren. Weitere Informationen zu Bicep finden Sie unter Bereitstellen und Verwalten von Ressourcen in Azure mithilfe von Bicep.