Grundlegendes zur Pull Request-Überprüfung
Wenn Sie Pull Requests verwenden, können Sie sicherstellen, dass alle Updates Ihrer Azure-Bereitstellungen von einer anderen Person überprüft werden. Es ist jedoch oft hilfreich, automatisierte Überprüfungen auch für Ihre Codeänderungen durchzuführen. In dieser Lektion erfahren Sie, wie Sie automatisierte Pull Request-Validierungen und -Überprüfungen verwenden können, um das Vertrauen Ihres Teams in Ihre Codeänderungen zu erhöhen.
Pull Request-Überprüfung
Wenn Sie einen Pull Request für Bicep-Code überprüfen, können Sie einige allgemeine Schritte ausführen, um die Änderung zu bewerten. Diese Schritte können Folgendes umfassen:
- Überprüfen Sie, ob die Bicep-Datei Fehler oder Linter-Warnungen enthält.
- Stellen Sie sicher, dass alle zuvor in der Bicep-Datei definierten Ressourcen weiterhin funktionieren.
- Testen Sie neu definierte Ressourcen, um sicherzustellen, dass sie erfolgreich bereitgestellt werden und wie erwartet funktionieren.
Die Pull Request-Überprüfung umfasst die Automatisierung einiger dieser Aktivitäten. Durch die Automatisierung von Pull Request-Überprüfungen stellen Sie sicher, dass Reviewer ihre Zeit mit anderen wichtigen Überprüfungsschritten verbringen, z. B. um sicherzustellen, dass der Code die Qualitätsstandards Ihres Teams erfüllt und das Geschäftsziel erreicht.
In einem GitHub Actions-Workflow können Sie Trigger definieren, die den Workflow an bestimmten Punkten während des Pull Request-Prozesses aufrufen, z. B. wenn ein Pull Request erstellt, aktualisiert, zusammengeführt oder geschlossen wird.
Testen Ihres Bicep-Codes in einem Workflow für die Pull Request-Überprüfung
In vorherigen Modulen haben Sie erfahren, wie Sie umfassende GitHub Actions-Workflows zum Linten, Überprüfen, Bereitstellen und Testen Ihrer Azure-Infrastrukturänderungen erstellen, auch in mehreren Umgebungen. Diese Workflows werden ausgeführt, nachdem Sie Ihre Änderungen mit Ihrem Mainbranch zusammengeführt haben.
Sie können auch viele der gleichen Aktivitäten in einem Workflow für die Pull Request-Überprüfung ausführen. Beispiel:
- Durch das Linten Ihres Bicep-Codes können Sie sicherstellen, dass der Code semantisch korrekt ist und einigen grundlegenden empfohlenen Bicep-Methoden folgt.
- Die Preflight-Überprüfung hilft Ihnen dabei, das Vertrauen zu schaffen, dass der Code erfolgreich bereitgestellt wird, ohne dass die Datei tatsächlich bereitgestellt wird. Je nach Ressourcentyp sucht die Preflightvalidierung möglicherweise nach Problemen wie ungültigen Ressourcennamen, ungültigen Regionen für bestimmte Ressourcen und ob Sie eine Konfiguration angegeben haben, die nicht erfolgreich bereitgestellt werden kann.
- Was-wäre-wenn: Listet die Änderungen auf, die an Ihrer Azure-Umgebung als Ergebnis der Bereitstellung vorgenommen werden.
- Bereitstellungen, um Ihre Ressourcen tatsächlich bereitzustellen und sicherzustellen, dass es keine Fehler bei der Bereitstellung gibt.
- Testen Sie Ihre Ressourcen nach der Bereitstellung, um sicherzustellen, dass sie gemäß Ihren Geschäftsanforderungen konfiguriert sind.
Ein Workflow für die Pull Request-Überprüfung ist ein normaler GitHub Actions-Workflow, sodass er jeden dieser Tasks ausführen kann. Es ist jedoch sinnvoll, über die Arten von Überprüfungen nachzudenken, die innerhalb eines Pull Requests ausgeführt werden sollten. Viele der hier aufgeführten Überprüfungsaktivitäten erfordern Zugriff auf eine Azure-Umgebung. Beispielsweise vergleicht der Was-wäre-wenn-Vorgang die in Ihren Bicep-Dateien definierten Ressourcen mit Ressourcen in Ihrem Azure-Abonnement. Es ist sinnvoll, diesen Vergleich mit einer Produktionsumgebung auszuführen, aber Sie sollten keine Vorgänge in einer Produktionsumgebung mit einem Workflow ausführen, der für noch nicht fertiggestellten oder zusammengeführten Code entwickelt wurde, da dies ein zusätzliches Risiko darstellt.
In diesem Modul fügen Sie Ihrem Workflow für Pull Request-Überprüfungen zwei Arten von Überprüfungen hinzu:
- Ausführen von Linting für Ihren Bicep-Code, um ihn einer ersten Prüfung zu unterziehen.
- Bereitstellen des Codes in einer neuen temporären Umgebung.
Für diese beiden Aktivitäten ist es nicht erforderlich, eine Verbindung mit Ihrer Azure-Produktionsumgebung oder sogar mit einer Ihrer regulären Nicht-Produktionsumgebungen wie Test, Qualitätssicherung oder Staging herzustellen. Indem Sie diese beiden Aktivitäten ausführen, können Sie immer noch ein gutes Maß an Vertrauen in Ihre Codeänderungen schaffen, sodass Sie sie im Mainbranch Ihres Repositorys zusammenführen können.
Die Überprüfungen sind für Ihre Reviewer nützlich, da sie Zeit sparen, die sonst für die manuelle Durchführung der Aktivitäten aufgewendet werden müsste. Die Prüfungen sind auch für Sie als Autor des Pull Requests nützlich, denn Sie können sie nutzen, um einen ersten Überblick darüber zu bekommen, wie Ihre Änderungen später im Bereitstellungsprozess funktionieren werden.
In Ihren eigenen Workflows für Pull Request-Überprüfungen können Sie die Überprüfungen durch zusätzliche Aktivitäten erweitern.
Trigger für den Pull Request-Lebenszyklus
Ein Pull Request in GitHub kann viele verschiedene Lebenszyklusereignisse durchlaufen. Beispiel: Ein Pull Request wird geöffnet. Dann könnte der Ersteller Änderungen zum Quellbranch pushen (synchronisieren), was sich auf den Inhalt des Pull Requests auswirkt. Als nächstes kann der Pull Request gemergt, ohne Merge geschlossen und sogar zu einem späteren Zeitpunkt erneut geöffnet werden.
Mit GitHub Actions können Sie Workflowtrigger definieren, die auf jedes dieser Ereignisse reagieren. Sie können z. B. einen Workflow definieren, der automatisch ausgeführt wird, sobald ein Pull Request geöffnet, synchronisiert oder erneut geöffnet wird, indem Sie den Trigger pull_request ohne zusätzliche Konfiguration angeben:
on: pull_request
Sie können auch Pull Request-Ereignisse angeben, die einen Workflow auslösen. Der folgende Workflow wird beispielsweise automatisch ausgeführt, wenn ein Pull Request geschlossen wird:
on:
pull_request:
types: [closed]
Wichtig
Wenn es in einem Pull Request Konflikte bei der Zusammenführung gibt, kann der Workflow nicht ausgeführt werden. Sie müssen den Konflikt auflösen und die Auflösung pushen, damit der Workflow ausgeführt werden kann.
Pull Request-Statusüberprüfungen
Die Ergebnisse eines Pull Request-Workflows werden auf der Detailseite des Pull Requests als Überprüfungen angezeigt. Mit Überprüfungen können Ersteller und Prüfer schnell Feedback dazu erhalten, ob die automatisierten Aktivitäten erfolgreich oder fehlerhaft waren, wie im folgenden Beispiel gezeigt:
Der Pull Request kann standardmäßig zusammengeführt werden, auch wenn bei einer Überprüfung ein Fehler auftritt. Möglicherweise möchten Sie dies nicht zulassen, sodass Sie die Regeln zum Schutz des Branches so konfigurieren können, dass bestimmte Überprüfungen erfolgreich sein müssen, bevor ein Pull Request zusammengeführt werden kann.
Aktualisieren von Dateien
Nachdem ein Pull Request erstellt wurde, muss der Ersteller häufig Updates durchführen. Beispiel:
- Ein Prüfer könnte den Ersteller auffordern, Änderungen am Code vorzunehmen.
- Wenn bei einer automatisierten Überprüfung ein Fehler auftritt, kann der Ersteller Änderungen am Code vornehmen, um das Problem zu beheben, und dann einen Commit ausführen und die Änderungen pushen.
Mithilfe des Triggers pull_request können Sie Ihren Überprüfungsworkflow so konfigurieren, dass er bei jeder Aktualisierung des Quellbranches ausgeführt wird. Die Ergebnisse der letzten Ausführung des Workflows werden auf der Detailseite des Pull Requests angezeigt.
Wiederverwendbare Workflows
Wenn Sie sich die Liste der möglichen Überprüfungen für die Pull Request-Überprüfung anzeigen, werden Sie feststellen, dass es sich dabei um die gleichen Schritte handelt, die Sie in Ihrem regulären Bereitstellungsworkflow ausführen würden. Zur Vermeidung von Wiederholungen ist es eine bewährte Methode, die wiederverwendbaren Workflows von GitHub zu verwenden.
Sie können wiederverwendbare Workflows für jeden der Aufträge definieren, die Sie in den verschiedenen Workflowdefinitionen verwenden. Die entsprechende Vorgehensweise wird in der nächsten Übung gezeigt.
Pull Requests entwerfen
Als Autor würden Sie normalerweise einen Pull Request öffnen, wenn Sie bereit sind, dass Ihre Änderungen geprüft, genehmigt und zusammengeführt werden. Es kann jedoch hilfreich sein, während des Schreibens Ihres Codes Zugang zu den automatischen Pull Request-Validierungsprüfungen zu erhalten, selbst wenn Sie noch nicht bereit sind, Ihre Änderungen zusammenzuführen.
Wenn Sie einen Pull Request auf GitHub öffnen, können Sie ihn als Entwurf markieren. GitHub führt dieselben automatisierten Prüfungen durch, und die Reviewer können weiterhin Feedback bereitstellen. Wenn sich Ihr Pull Request jedoch im Entwurfsstatus befindet, ist es für jeden Benutzer klar, dass die Arbeit noch nicht bereit für eine vollständige Überprüfung ist und nicht gemergt werden kann.
Es ist insbesondere üblich, Pull Request-Entwürfe zu erstellen, wenn Ihr Workflow für Pull Request-Überprüfungen kurzlebige Umgebungen erstellt, da Sie Ihre Änderungen in einer Live-Arbeitsumgebung in der Vorschau anzeigen können. Wenn Sie weiterhin Änderungen pushen, wird Ihre kurzlebige Umgebung aktualisiert, um Ihre neuesten Änderungen zu integrieren.