Entwerfen der Pipeline
In dieser Lektion folgen Sie dem Tailspin-Webteam bei der Definition seiner Releasepipeline für die Website Space Game.
Wenn Sie eine Releasepipeline planen, beginnen Sie in der Regel damit, die Phasen oder Hauptunterteilungen dieser Pipeline zu identifizieren. Jede Phase entspricht typischerweise einer Umgebung. Im vorherigen Modul besaß die einfache Pipeline von Andy und Mara beispielsweise eine Deploy-Phase (Bereitstellen), die einer Azure App Service-Instanz zugeordnet war.
In diesem Modul stufen Sie Änderungen von einer Phase zur nächsten höher. Innerhalb jeder Phase stellen Sie die Website Space Game in der dieser Phase zugeordneten Umgebung bereit.
Nachdem Sie definiert haben, welche Phasen Sie benötigen, überlegen Sie, wie Änderungen von einer Phase zur nächsten höhergestuft werden. Jede Phase kann die Erfolgskriterien definieren, die erfüllt sein müssen, bevor der Build zur nächsten Phase übergehen kann. Azure Pipelines bietet mehrere Möglichkeiten, mit denen Sie steuern können, wie und wann Änderungen die Pipeline durchlaufen. In ihrer Gesamtheit werden diese Ansätze für die Releaseverwaltung verwendet.
In diesem Abschnitt führen Sie folgende Schritte aus:
- Kennenlernen der Unterschiede zwischen den gängigen Pipelinephasen, z. B. Build (Erstellen), Dev (Entwicklung), Test und Staging.
- Verstehen, wie Sie mit manuellen und geplanten Bereitstellungstriggern sowie mit Continuous Deployment-Triggern steuern können, wann ein Artefakt zur nächsten Phase der Pipeline übergeht.
- Nachvollziehen, wie eine Releasegenehmigung die Pipeline anhält, bis eine genehmigende Person das Release akzeptiert oder ablehnt.
Die Besprechung
Das gesamte Tailspin-Webteam ist versammelt. In Erstellen einer Releasepipeline mit Azure Pipelines hat das Team seine Aufgaben für den aktuellen Sprint geplant. Jede Aufgabe bezieht sich auf das Erstellen ihrer Releasepipeline für die Website Space Game.
Erinnern Sie sich daran, dass sich das Team auf diese fünf Aufgaben für den Sprint geeinigt hatte:
- Erstellen einer mehrstufigen Pipeline.
- Verbinden der Web-App mit einer Datenbank.
- Automatisieren der Qualitätstests.
- Automatisieren der Leistungstests.
- Verbessern der Releasekadenz.
Das Team trifft sich, um die erste Aufgabe zu besprechen, das Erstellen einer mehrstufigen Pipeline. Nachdem das Team die Pipeline definiert hat, kann es von einem einfachen Proof-of-Concept zu einer Releasepipeline übergehen, die weitere Phasen, Qualitätsprüfungen und Genehmigungen umfasst.
Amita und Tim sehen Andy und Mara zu, wie sie die Releasepipeline ein zweites Mal demonstrieren. Sie sehen, dass das Artefakt erstellt und in App Service installiert wird.
Welche Pipelinephasen benötigen Sie?
Wenn Sie eine Releasepipeline implementieren möchten, ist es wichtig, zunächst zu ermitteln, welche Phasen Sie benötigen. Welche Phasen Sie auswählen, hängt von Ihren Anforderungen ab. Begleiten wir das Team bei der Entscheidung über seine Phasen.
Tim: OK, ich verstehe die Idee einer automatisierten Pipeline. Mir gefällt, dass es einfach auf Azure bereitgestellt werden kann. Aber wie geht es nach dieser Demo weiter? Wir brauchen etwas, das wir tatsächlich für unsere Releases verwenden können.
Amita: Stimmt. Wir müssen weitere Phasen hinzufügen. Zum Beispiel haben wir derzeit keine Zeit für eine Testphase.
Tim: Außerdem brauchen wir eine Phase, in der wir dem Management neue Features zeigen können. Ich kann nichts ohne Genehmigung des Managements an die Produktion schicken.
Andy: Auf jeden Fall! Nun, da wir wissen, was eine Releasepipeline tut, wie können wir diese Pipeline dazu bringen, das zu tun, was wir benötigen?
Mara: Lasst uns unsere Anforderungen skizzieren, damit wir unsere nächsten Schritte planen können. Beginnen wir mit dem, was wir haben.
Mara geht zum Whiteboard und skizziert die bestehende Pipeline.
Mara: In der Build-Phase wird der Quellcode erstellt und ein Paket erzeugt. In unserem Fall ist dieses Paket eine ZIP-Datei. In der Deploy-Phase wird die ZIP-Datei, bei der es sich um die Website Space Game handelt, in einer App Service-Instanz installiert. Was fehlt noch in unserer Releasepipeline?
Hinzufügen der Dev-Phase
Andy: Ich bin vielleicht voreingenommen, aber ich denke, wir brauchen eine Dev-Phase. Diese Phase sollte die erste Station für das Artefakt sein, nachdem es erstellt wurde. Entwickler können nicht immer den gesamten Dienst aus ihrer lokalen Entwicklungsumgebung ausführen. Ein E-Commerce-System kann z. B. eine Website, Produktdatenbank und ein Zahlungssystem erfordern. Wir brauchen eine Phase, die alles enthält, was die App braucht.
In unserem Fall liest die Bestenlistenfunktion (Leaderboard) der Website Space Game Bestenpunktzahlen (Highscores) aus einer externen Quelle. Im Moment liest sie fiktive Punktzahlen aus einer Datei. Das Einrichten einer Dev-Phase würde uns eine Umgebung liefern, in der wir die Web-App mit einer echten Datenbank integrieren können. Diese Datenbank enthält zwar eventuell immer noch fiktive Punktzahlen, aber sie bringt uns unserer endgültigen App einen Schritt näher.
Mara: Mir gefällt‘s. Wir werden noch keine Integration mit einer echten Datenbank vornehmen. Aber in einer Dev-Phase können wir in einer Umgebung bereitstellen, in der wir eine Datenbank hinzufügen können.
Mara aktualisiert ihre Zeichnung auf dem Whiteboard. Sie ersetzt „Deploy“ durch „Dev“, um die Dev-Phase darzustellen.
Andy: Da sprichst du einen interessanten Punkt an. Wir erstellen die App jedes Mal, wenn wir eine Änderung auf GitHub pushen. Bedeutet das, dass jeder Build nach seiner Fertigstellung in die Dev-Phase höhergestuft wird?
Mara: Kontinuierliches Erstellen liefert uns wichtiges Feedback über unseren Build- und Testzustand. Aber wir wollen nur dann in die Dev-Phase höherstufen, wenn wir Code in einem zentralen Branch zusammenführen: entweder in „main“ oder in einen anderen Releasebranch. Ich aktualisiere die Zeichnung, um diese Anforderung darzustellen.
Mara: Ich denke, diese Höherstufung lässt sich leicht bewerkstelligen. Wir können eine Bedingung definieren, die nur dann zur Dev-Phase höherstuft, wenn Änderungen in einem Releasebranch stattfinden.
Was sind Bedingungen?
Verwenden Sie in Azure Pipelines eine Bedingung zum Ausführen einer Aufgabe oder eines Auftrags basierend auf dem Zustand der Pipeline. Sie haben in vorherigen Modulen schon mit Bedingungen gearbeitet.
Denken Sie daran, dass einige der Bedingungen, die Sie angeben können, folgende sind:
- Nur wenn alle vorherigen abhängigen Aufgaben erfolgreich waren.
- Auch wenn eine vorherige Abhängigkeit fehlgeschlagen ist, außer wenn die Ausführung abgebrochen wurde.
- Auch wenn eine vorherige Abhängigkeit fehlgeschlagen ist, auch wenn die Ausführung abgebrochen wurde.
- Nur wenn eine vorherige Abhängigkeit fehlgeschlagen ist.
- Einige benutzerdefinierte Bedingungen.
Im Folgenden finden Sie ein einfaches Beispiel:
steps:
- script: echo Hello!
condition: always()
Die always()-Bedingung bewirkt, dass diese Aufgabe bedingungslos "Hello!" ausdruckt, auch wenn vorherige Aufgaben fehlgeschlagen sind.
Diese Bedingung wird verwendet, wenn Sie keine Bedingung angeben:
condition: succeeded()
Die integrierte Funktion succeeded() prüft, ob die vorherige Aufgabe erfolgreich war. Wenn die vorherige Aufgabe fehlerhaft ist, werden diese und spätere Aufgaben, die dieselbe Bedingung verwenden, übersprungen.
Hier sollten Sie eine Bedingung erstellen, die angibt:
- Die vorherige Aufgabe war erfolgreich.
- Der Name des aktuellen Git-Branch ist release.
Um diese Bedingung zu erstellen, verwenden Sie die integrierte Funktion and(). Diese Funktion prüft, ob jede ihrer Bedingungen wahr ist. Wenn eine Bedingung nicht wahr ist, schlägt die Gesamtbedingung fehl.
Um den Namen des aktuellen Branch zu erhalten, verwenden Sie die integrierte Variable Build.SourceBranchName. Sie können auf Variablen innerhalb einer Bedingung auf mehrere Arten zugreifen. Hier verwenden Sie die variables[]-Syntax.
Um den Wert einer Variablen zu testen, können Sie die integrierte Funktion eq() verwenden. Diese Funktion prüft, ob ihre Argumente gleich sind.
Dies im Hinterkopf, wenden Sie diese Bedingung an, um die Dev-Phase nur dann auszuführen, wenn der aktuelle Branchname „release“ lautet:
condition: |
and
(
succeeded(),
eq(variables['Build.SourceBranchName'], 'release')
)
Die erste Bedingung in der and()-Funktion prüft, ob die vorherige Aufgabe erfolgreich war. Die zweite Bedingung prüft, ob der aktuelle Branchname gleich release ist.
In YAML verwenden Sie die Pipe-Syntax (|), um eine Zeichenfolge zu definieren, die mehrere Zeilen umfasst. Sie könnten die Bedingung in einer einzigen Zeile definieren, aber wir schreiben sie so, damit sie besser lesbar ist.
Hinweis
In diesem Modul verwenden wir den Branch release als Beispiel. Sie können Bedingungen kombinieren, um das gewünschte Verhalten zu definieren. Sie könnten zum Beispiel eine Bedingung erstellen, die die Phase nur dann ausführt, wenn der Build von einem Pull Request für den main-Branch ausgelöst wird.
In der nächsten Lerneinheit, wenn Sie die Dev-Stufe einrichten, arbeiten Sie mit einem vollständigeren Beispiel.
Eine umfassendere Beschreibung der Bedingungen in Azure Pipelines finden Sie in der Dokumentation der Ausdrücke.
Mara: Mithilfe von Bedingungen können wir steuern, welche Änderungen auf welchen Phasen heraufgestuft werden. Wir können für jede Änderung ein Buildartefakt erzeugen, um unseren Build zu überprüfen und seine Integrität zu bestätigen. Wenn wir bereit sind, können wir diese Änderungen in einen Releasebranch zusammenführen und diesen Build in die Dev-Phase höherstufen.
Hinzufügen der Test-Phase
Mara: Bisher haben wir die Phasen Build und Dev. Was kommt als Nächstes?
Amita: Können wir als Nächstes die Test-Phase hinzufügen? Das scheint mir die richtige Stelle zu sein, um die neuesten Änderungen zu testen.
Mara ergänzt Ihre Zeichnung um die Test-Phase auf dem Whiteboard.
Amita: Eine Frage, die ich mir stelle, ist, wie oft ich die App testen muss. Eine E-Mail benachrichtigt mich, wenn Mara oder Andy eine Änderung vornimmt. Veränderungen erfolgen im Laufe des Tages, und ich weiß nie, wann ich tätig werden soll. Ich denke, ich würde gerne einmal am Tag einen Build sehen, vielleicht wenn ich ins Büro komme. Können wir das machen?
Andy: Sicher. Warum führen wir die Bereitstellung in Test nicht außerhalb der Geschäftszeiten durch? Angenommen, wir senden dir jeden Tag um 3 Uhr morgens einen Build.
Mara: Das klingt gut. Wir können den Prozess bei Bedarf auch jederzeit noch mal manuell auslösen. Wir können ihn zum Beispiel auslösen, wenn du einen wichtigen Bugfix sofort überprüfen musst.
Mara aktualisiert ihre Zeichnung dahingehend, dass der Build jeden Morgen um 3 Uhr von der Dev-Phase in die Test-Phase wechselt.
Was sind Trigger?
Amita: Jetzt, wo wir wissen, wie eine Phase in die andere übergeht, fühle ich mich schon besser. Aber wie können wir steuern, wann eine Phase ausgeführt wird?
Mara: In Azure Pipelines können wir Trigger verwenden. Ein Trigger definiert, wann eine Phase ausgeführt wird. Azure Pipelines bietet ein paar Arten von Triggern. Hier sehen Sie unsere Auswahlmöglichkeiten:
- Continuous Integration-Trigger (CI)
- Pull Request-Trigger (PR)
- Geplanter Trigger
- Buildabschlusstrigger
Mit CI- und PR-Triggern können Sie steuern, welche Branches am Gesamtprozess teilnehmen. Sie möchten zum Beispiel das Projekt erstellen, wenn eine Änderung in einem beliebigen Branch vorgenommen wird. Ein geplanter Trigger startet eine Bereitstellung zu einer bestimmten Zeit. Ein Buildabschlusstrigger führt einen Build aus, wenn ein anderer Build, z. B. einer für eine abhängige Komponente, erfolgreich abgeschlossen wird. Es scheint, dass wir einen geplanten Trigger brauchen.
Was sind geplante Trigger?
Ein geplanter Trigger verwendet die cron-Syntax, um die Ausführung eines Builds nach einem definierten Zeitplan zu veranlassen.
Auf Unix- und Linux-Systemen ist „cron“ eine beliebte Methode, um die Ausführung von Aufträgen in einem bestimmten Zeitintervall oder zu einem bestimmten Zeitpunkt zu planen. In Azure Pipelines verwenden geplante Trigger die cron-Syntax, um festzulegen, wann eine Phase ausgeführt wird.
Ein cron-Ausdruck umfasst Felder, die bestimmten Zeitparametern entsprechen. Dies sind die Felder:
mm HH DD MM DW
\ \ \ \ \__ Days of week
\ \ \ \____ Months
\ \ \______ Days
\ \________ Hours
\__________ Minutes
Zum Beispiel beschreibt dieser cron-Ausdruck „3 Uhr morgens jeden Tag“: 0 3 * * *
Ein cron-Ausdruck kann Sonderzeichen enthalten, um eine Liste oder einen Bereich von Werten anzugeben. In diesem Beispiel entspricht das Sternchen (*) allen Werten für die Felder Tage, Monate und Wochentage.
Anders ausgedrückt, liest sich dieser cron-Ausdruck wie folgt:
- Zur Minute 0,
- Zur dritten Stunde,
- An jedem Tag des Monats,
- In jedem Monat,
- An jedem Tag der Woche,
- Ausführung des Auftrags.
Zur Angabe von 3 Uhr morgens nur an den Tagen Montag bis Freitag, würden Sie diesen Ausdruck verwenden: 0 3 * * 1-5
Hinweis
Die Zeitzone für cron-Zeitpläne ist koordinierte Weltzeit (UTC, Coordinated Universal Time), weshalb sich in diesem Beispiel also 3 Uhr morgens auf 3 Uhr in UTC bezieht. In der Praxis sollten Sie vielleicht die Zeit in Ihrem cron-Zeitplan relativ zur UTC anpassen, damit die Pipeline zur von Ihnen und Ihrem Team erwarteten Zeit ausgeführt wird.
Um einen geplanten Trigger in Azure Pipelines einzurichten, benötigen Sie einen Abschnitt schedules in Ihrer YAML-Datei. Hier sehen Sie ein Beispiel:
schedules:
- cron: '0 3 * * *'
displayName: 'Deploy every day at 3 A.M.'
branches:
include:
- release
always: false
In diesem Abschnitt schedules:
- gibt
cronden cron-Ausdruck an. - gibt
branchesan, dass die Bereitstellung nur aus dem Branchreleaseerfolgen soll. - gibt
alwaysan, ob die Bereitstellung ohne Bedingung ausgeführt werden soll (true), oder nur, wenn sich derrelease-Branch seit der letzten Ausführung geändert hat (false). Hier geben Siefalsean, weil Sie nur dann bereitstellen müssen, wenn sich der Branchreleaseseit der letzten Ausführung geändert hat.
Die gesamte Pipeline wird ausgeführt, wenn Azure Pipelines einen geplanten Trigger ausführt. Die Pipeline wird auch unter anderen Bedingungen ausgeführt, z. B. wenn Sie eine Änderung in GitHub pushen. Um eine Phase nur als Reaktion auf einen geplanten Trigger auszuführen, können Sie eine Bedingung verwenden, die überprüft, ob der Grund für den Build eine geplante Ausführung ist.
Hier sehen Sie ein Beispiel:
- stage: 'Test'
displayName: 'Deploy to the Test environment'
condition: and(succeeded(), eq(variables['Build.Reason'], 'Schedule'))
Diese Phase, Test, wird nur ausgeführt, wenn die vorherige Phase erfolgreich war und die integrierte Pipeline-Variable Build.Reason gleich Schedule ist.
Ein ausführlicheres Beispiel sehen Sie später in diesem Modul.
Amita: Das gefällt mir. Ich muss das Release nicht einmal manuell abholen und installieren. Es ist bereit für mich.
Andy: Und denk dran, wenn wir später noch mehr automatisieren wollen, können wir das auch. Nichts ist in Stein gemeißelt. Die Pipeline entwickelt sich zusammen mit uns weiter, während wir besser werden und lernen.
Hinzufügen der Staging-Phase
Tim: Jetzt bin ich dran. Ich brauche eine Phase, um weitere Belastungstests durchzuführen. Wir brauchen auch eine Phase, in der wir dem Management eine Demo vorführen können, um ihre Genehmigung zu erhalten. Für den Moment können wir diese beiden Anforderungen in einer Phase kombinieren, die wir Staging nennen können.
Andy: Gut formuliert, Tim. Es ist wichtig, eine Staging- oder Vorproduktionsumgebung zu haben. Diese Stagingumgebung ist oft die letzte Station, bevor ein Feature oder ein Bugfix unsere Benutzer erreicht.
Mara ergänzt in ihrer Zeichnung auf dem Whiteboard Staging.
Amita: Wir verwenden einen geplanten Trigger, um Änderungen aus der Dev-Phase in die Test-Phase höherzustufen. Aber wie können wir Änderungen von Test nach Staging übertragen? Muss diese Höherstufung auch nach einem bestimmten Zeitplan erfolgen?
Mara: Ich denke, der beste Weg, das zu handhaben, wäre eine Releasegenehmigung. Mit einer Releasegenehmigung können Sie eine Änderung manuell von einer Phase in die nächste höherstufen.
Amita: Das klingt genau nach dem, was ich brauche! Eine Releasegenehmigung würde mir die Zeit verschaffen, die neuesten Änderungen zu testen, bevor wir den Build dem Management präsentieren. Ich kann den Build dann höherstufen, wenn ich bereit bin.
Mara aktualisiert ihre Zeichnung so, dass nun zu sehen ist, dass der Build nur dann von Test zu Staging wechselt, wenn Amita ihn genehmigt.
Tim: Ich könnte mir auch vorstellen, Releasegenehmigungen zu verwenden, um von Staging zu Production (Produktion) höherzustufen, nachdem das Management die Freigabe erteilt hat. Ich kann nie vorhersagen, wie lange das dauert. Nachdem sie abgezeichnet haben, kann ich das Release genehmigen und es manuell in die Produktion höherstufen. Aber wie funktionieren Releasegenehmigungen?
Was sind Releasegenehmigungen?
Eine Releasegenehmigungen ist eine Möglichkeit, die Pipeline anzuhalten, bis eine genehmigende Person das Release akzeptiert oder ablehnt. Um Ihren Releaseworkflow zu definieren, können Sie Genehmigungen, Bedingungen und Trigger kombinieren.
Erinnern Sie sich, dass Sie in Erstellen einer Releasepipeline mit Azure Pipelines eine Umgebung in Ihrer Pipelinekonfiguration definiert haben, um Ihre Bereitstellungsumgebung darzustellen. Hier ist ein Beispiel aus Ihrer bestehenden Pipeline:
- stage: 'Deploy'
displayName: 'Deploy the web application'
dependsOn: Build
jobs:
- deployment: Deploy
pool:
vmImage: 'ubuntu-20.04'
environment: dev
variables:
- group: Release
Ihre Umgebung kann bestimmte Kriterien für Ihr Release enthalten. Die Kriterien können festlegen, welche Pipelines in dieser Umgebung bereitgestellt werden können und welche menschlichen Genehmigungen erforderlich sind, um das Release von einer Phase zur nächsten höherzustufen.
Später in diesem Modul definieren Sie die Staging-Umgebung und weisen sich selbst als Genehmiger*in zu, um die Space Game-Webanwendung von der Testphase in die Staging-Umgebung zu verschieben.
So wenig oder so viel automatisieren, wie Sie benötigen
Azure Pipelines bietet Ihnen die Flexibilität, einige Phasen zu automatisieren, während Sie Phasen, die nicht für die Automatisierung bereit sind, manuell steuern können.
Tim: Mir gefällt, wie wir die Kriterien definieren können, die Änderungen von einer Phase zur nächsten höherstufen. Aber wir haben einige manuelle Kriterien in unserer Pipeline definiert. Ich dachte, bei DevOps geht es darum, alles zu automatisieren.
Mara: Da sprichst du einen guten Punkt an. Bei DevOps geht es eigentlich um die Automatisierung sich wiederholender und fehleranfälliger Aufgaben. Manchmal ist menschliches Eingreifen notwendig. Zum Beispiel holen wir die Genehmigung des Managements ein, bevor wir neue Funktionen freigeben. Je mehr Erfahrung wir mit unseren automatisierten Bereitstellungen sammeln, desto mehr manuelle Schritte können wir automatisieren, um den Prozess zu beschleunigen. So können wir beispielsweise mehr Qualitätsprüfungen in der Testphase automatisieren, so dass Amita nicht jeden Build genehmigen muss.
Tim: Klingt gut. Bleiben wir vorerst bei diesem Plan, und schauen wir, wie wir das System später beschleunigen können.
Amita: Apropos unser Plan, können wir unsere nächsten Schritte zusammenfassen?
Der Plan
Sehen wir uns den Plan des Tailspin-Teams für die nächsten Schritte an.
Mara: Das ist die Releasepipeline, die wir erstellen möchten.
Mara zeigt auf das Whiteboard.
Mara: Zusammenfassend lauten unsere Schritte wie folgt:
- Erzeugen eines Buildartefakts bei jedem Push einer Änderung in GitHub. Dieser Schritt erfolgt in der Build-Phase.
- Höherstufen des Buildartefakts in die Dev-Phase. Dieser Schritt erfolgt automatisch, wenn die Build-Phase erfolgreich war und sich die Änderung im Releasebranch befindet.
- Das Buildartefakt jeden Morgen um 3 Uhr in die Testphase heraufstufen. Wir verwenden einen geplanten Trigger, um das Buildartefakt automatisch heraufzustufen.
- Höherstufen des Buildartefakts zum Staging, nachdem Amita den Build getestet und genehmigt hat. Wir verwenden eine Releasegenehmigung, um das Buildartefakt höherzustufen.
Nachdem das Management den Build genehmigt hat, können wir das Buildartefakt in einer Produktionsumgebung bereitstellen.
Amita: Wird sich das schwer bewerkstelligen lassen? Es scheint eine Menge Arbeit zu sein.
Mara: Ich denke, das ist nicht so schlimm. Jede Phase ist von jeder anderen Phase getrennt. Phasen sind diskret. Jede Phase hat ihren eigenen Aufgabenkatalog. Was z. B. in der Test-Phase passiert, bleibt in der Test-Phase.
Jede Bereitstellungsphase in unserer Pipeline besitzt auch ihre eigene Umgebung. Wenn wir zum Beispiel die App in Dev oder Test bereitstellen, ist die Umgebung eine App Service-Instanz.
Schließlich testen wir immer nur ein Release gleichzeitig. Wir ändern niemals Releases in der Mitte der Pipeline. Wir verwenden in der Dev-Phase dieselbe Version wie in der Staging-Phase, und jedes Release hat seine eigene Versionsnummer. Wenn das Release in einer der Phasen beschädigt wird, beheben wir es und erstellen es mit einer neuen Versionsnummer erneut. Dieses neue Release durchläuft dann die Pipeline wieder von Anfang an.
Ein paar Worte zur Qualität
Sie haben gerade gesehen, wie das Team eine Pipeline entwickelt hat, die ihre App vom Build direkt zur Staging-Phase verschiebt. Der Sinn dieser Pipeline ist nicht nur, ihnen das Leben leichter zu machen. Es geht darum, die Qualität der Software zu gewährleisten, die sie ihren Kunden liefern.
Wie messen Sie die Qualität Ihres Releaseprozesses? Die Qualität Ihres Releaseprozesses kann nicht direkt gemessen werden. Was Sie messen können, ist, wie gut Ihr Prozess funktioniert. Wenn Sie den Prozess ständig ändern, könnte das ein Hinweis darauf sein, dass etwas nicht stimmt. Releases, die konsistent an einem bestimmten Punkt in der Pipeline fehlschlagen, können auch darauf hinweisen, dass es ein Problem mit dem Releaseprozess gibt.
Schlagen die Releases immer an einem bestimmten Tag oder zu einer bestimmten Uhrzeit fehl? Schlagen sie immer fehl, nachdem sie in einer bestimmten Umgebung bereitgestellt wurden? Suchen Sie nach solchen und anderen Mustern, um herauszufinden, ob Aspekte des Releaseprozesses davon abhängig sind oder damit in Zusammenhang stehen.
Eine gute Möglichkeit, den Überblick über die Qualität Ihres Releaseprozesses zu behalten, ist die Erstellung von Visualisierungen der Qualität der Releases. Fügen Sie zum Beispiel ein Dashboard-Widget hinzu, das Ihnen den Status jedes Releases anzeigt.
Wenn Sie die Qualität eines Releases selbst messen wollen, können Sie alle möglichen Überprüfungen innerhalb der Pipeline durchführen. Sie können zum Beispiel verschiedene Arten von Tests wie Auslastungstests und Benutzeroberflächentests ausführen, während Ihre Pipeline ausgeführt wird.
Die Verwendung eines Quality Gates ist auch eine gute Möglichkeit, die Qualität Ihres Releases zu überprüfen. Es gibt viele verschiedene Quality Gates. Zum Beispiel können Gates für Arbeitselemente die Qualität Ihres Anforderungsprozesses überprüfen. Sie können auch weitere Sicherheits- und Compliance-Prüfungen hinzufügen. Halten Sie zum Beispiel das Vier-Augen-Prinzip ein oder verfügen Sie über die richtige Nachverfolgbarkeit?
Während Sie auf diesem Lernpfad voranschreiten, werden Sie viele dieser Techniken in der Praxis anwenden können.
Und schließlich sollten Sie bei der Entwicklung eines qualitativ hochwertigen Freigabeprozesses darüber nachdenken, welche Art von Dokumentation oder Versionshinweisen Sie Benutzer*innen zur Verfügung stellen müssen. Es kann schwierig sein, Ihre Dokumentation auf dem aktuellen Stand zu halten. Sie könnten die Verwendung eines Tools in Betracht ziehen, wie z. B. den Azure DevOps Release Notes Generator. Der Generator ist eine Funktions-App, die eine HTTP-ausgelöste Funktion enthält. Sie erstellt immer unter Verwendung von Azure Blob Storage eine Markdowndatei, wenn ein neues Release in Azure DevOps erstellt wird.