Überprüfen und Zusammenführen von Bicep-Änderungen
Sie haben gelernt, wie Sie Featurebranches verwenden und Branchschutz anwenden, um sicherzustellen, dass Änderungen überprüft werden, bevor sie zusammengeführt werden. Nun müssen Sie einen konsistenten Prozess befolgen, um Ihre Änderungen vorzuschlagen und zu überprüfen, bevor sie zusammengeführt werden.
In dieser Lerneinheit erfahren Sie mehr über Pull Requests, einschließlich ihrer Erstellung und Verwendung. Außerdem erfahren Sie, wie Sie Pull Requests verwenden können, um Bicep-Code zu überprüfen.
Pull Requests
Ein Pull Request ist eine Anforderung von Ihnen, dem Entwickler eines Features, an den Betreuer des Mainbranchs. Sie bitten den Betreuer, Ihre Änderungen in den Mainbranch des Repositorys zu pullen.
Pull Requests und Branchschutz
Wenn Sie Branchschutz konfigurieren, können Sie von den Codebesitzern verlangen, den Pull Request zu überprüfen. Beispielsweise können Sie die Projektleiter als Prüfer für alle Ihre Pull Requests einschließen, oder Sie können angeben, dass eine bestimmte Anzahl von Personen jeden Pull Request überprüfen muss.
Pull Requests und Branchrichtlinien
Wenn Sie Branchrichtlinien konfigurieren, können Sie verlangen, dass bestimmte Personen oder eine Gruppe von Personen den Pull Request überprüfen. Beispielsweise können Sie die Projektleiter als Prüfer für alle Ihre Pull Requests einschließen, oder Sie können angeben, dass eine bestimmte Anzahl von Personen jeden Pull Request überprüfen muss.
Sie können auch verlangen, dass jeder Pull Request mit einem Arbeitselement verknüpft ist. Mit dieser Konfiguration können Sie den Ablauf von einem Arbeitselement, das eine Featureanforderung an den Code enthält, der die Änderung implementiert, bis hin zur Bereitstellung in Ihrer Produktionsumgebung verfolgen.
Erstellen eines Pull Request
Sie können mithilfe der GitHub-Webbenutzeroberfläche einen Pull Request erstellen. Sie wählen den Quellbranch aus, in dem Sie Ihre Änderungen vorgenommen haben, und den Zielbranch, der normalerweise der Mainbranch des Repositorys ist.
Sie können mithilfe der Azure DevOps-Webbenutzeroberfläche einen Pull Request erstellen. Sie wählen den Quellbranch aus, in dem Sie Ihre Änderungen vorgenommen haben, und den Zielbranch, der normalerweise der Mainbranch des Repositorys ist.
Wenn Sie einen Pull Request erstellen, müssen Sie ihm einen Namen geben. Es ist eine bewährte Methode, klare und verständliche Pull Request-Namen zu wählen. So helfen Sie Ihren Teammitgliedern, den Kontext des zu überprüfenden Themas zu verstehen. Wenn sie über unterschiedliche Fachkenntnisse verfügen, kann ein guter Name ihnen helfen, Pull Requests zu finden, zu denen sie aussagekräftiges Feedback beitragen können, und die nicht relevanten Pull Requests zu überspringen.
Außerdem werden Pull Request-Namen häufig Teil des Verlaufs Ihres Git-Repositorys. Daher sollten sie verständlich sein, wenn jemand den Verlauf anzeigt.
Sie können Pull Requests auch eine Beschreibung geben. Sie können bestimmte Personen oder Probleme in Ihren Beschreibungen erwähnen. Viele Teams erstellen standardisierte Vorlagen für Pull Request-Beschreibungen, damit klar ist, was jede Änderung ist.
Sie können Pull Requests auch eine Beschreibung geben. Sie können bestimmte Personen oder Arbeitselemente in Ihren Beschreibungen erwähnen. Viele Teams erstellen standardisierte Vorlagen für Pull Request-Beschreibungen, damit klar ist, was jede Änderung ist.
Wenn Sie einen Pull Request erstellen, können Sie Personen einladen, die Änderungen zu überprüfen.
Manchmal erstellen Sie einen Pull Request, nur um Feedback von Ihren Kollegen zu erhalten. In diesen Situationen können Sie angeben, dass der Pull Request ein Entwurf ist. Prüfer wissen, dass Sie noch an den Änderungen arbeiten. Ihre Prüfer können weiterhin Feedback geben, aber es ist klar, dass die Änderungen noch nicht zusammengeführt werden können. Wenn Sie mit Ihren Änderungen zufrieden sind, können Sie den Entwurfsstatus entfernen.
Auch nachdem Sie einen Pull Request erstellt haben, können Sie weiterhin Änderungen am Code in Ihrem Featurebranch vornehmen. Diese Änderungen werden Teil des Pull Requests.
Überprüfen eines Pull Requests
Wenn Sie einen Pull Request überprüfen, können Sie alle Änderungen sehen. Sie können den gesamten Pull Request oder nur bestimmte Teile der geänderten Dateien kommentieren. Der Autor des Pull Requests kann auf Kommentare reagieren, und andere Prüfer können an Diskussionen teilnehmen. Diese Kommentarfunktionen machen die Zusammenarbeit an Pull Requests zu einer interaktiven Erfahrung.
Wenn Sie den Bicep-Code überprüfen, suchen Sie nach den folgenden Schlüsselelementen:
- Kann die Datei bereitgestellt werden? Stellen Sie den Bicep-Code vor dem Zusammenführen bereit, und testen Sie ihn. Stellen Sie sicher, dass keine Linterwarnungen angezeigt werden, und dass die Azure-Bereitstellung erfolgreich ist. In einem zukünftigen Microsoft Learn-Modul lernen Sie Ansätze zur automatischen Bereitstellung und Überprüfung Ihrer Änderungen.
- Ist der Bicep-Code klar und verständlich? Es ist wichtig, dass alle Teammitglieder Ihren Bicep-Code verstehen. Wenn Sie eine Bicep-Datei in einem Pull Request überprüfen, stellen Sie sicher, dass Sie genau verstehen, wofür jede Änderung verwendet werden soll. Sind Variablen und Parameter gut benannt? Wurden Kommentare verwendet, um komplexe Codeabschnitte zu erläutern?
- Ist die Änderung abgeschlossen? Wenn dieser Pull Request Teil einer größeren Arbeit ist, stellen Sie sicher, dass Ihre Umgebung funktioniert, wenn diese Änderung zusammengeführt und bereitgestellt wird. Wenn der Pull Request beispielsweise eine Azure-Ressource als Vorbereitung auf eine spätere Änderung neu konfiguriert, stellen Sie sicher, dass die Ressource während des gesamten Prozesses weiterhin ordnungsgemäß funktioniert. Wenn der Pull Request eine neue Azure-Ressource hinzufügt, die noch nicht benötigt wird, sollten Sie überlegen, ob eine Bedingung vorübergehend hinzugefügt werden soll, damit die Ressource erst bereitgestellt wird, wenn sie benötigt wird.
- Folgt die Änderung bewährten Bicep-Methoden? In anderen Microsoft Learn-Modulen haben Sie mehr über die Elemente des guten Bicep-Codes erfahren. Stellen Sie sicher, dass der Code, den Sie überprüfen, den gleichen bewährten Methoden entspricht.
- Stimmt die Änderung mit der Beschreibung überein? Pull Requests sollten einen beschreibenden Titel enthalten. Viele Teams erfordern auch, dass Pull Requests eine Beschreibung der Änderung und ihres Zwecks enthalten. Überprüfen Sie, ob die Änderungen am Bicep-Code mit den Pull Request-Details übereinstimmen. Wenn der Pull Request-Autor Verknüpfungen zu Arbeitselementen oder Problemen eingerichtet hat, überprüfen Sie, ob die Änderungen im Pull Request die Erfolgskriterien erfüllen, die das Arbeitselement definiert hat.
Abschließen eines Pull Requests
Nachdem der Pull Request genehmigt wurde, kann er abgeschlossen werden. Das bedeutet, dass die Inhalte des Pull Requests mit dem Mainbranch zusammengeführt werden.
In einigen Teams sollte der Autor des Pull Requests den Pull Request auch abschließen. Durch diesen Prozess wird sichergestellt, dass der Autor steuert, wann die Zusammenführung erfolgt und für die Überwachung automatisierter Bereitstellungen verfügbar sein kann. In anderen Teams schließen genehmigende Personen den Pull Request ab. Ihr Team sollte entscheiden, wer Pull Requests wann zusammenführt.
In einigen Teams sollte der Autor des Pull Requests den Pull Request auch abschließen. Durch diesen Prozess wird sichergestellt, dass der Autor steuert, wann die Zusammenführung erfolgt und für die Überwachung automatisierter Bereitstellungen verfügbar sein kann. In anderen Teams schließen genehmigende Personen den Pull Request ab. Sie können sogar mit Azure DevOps einen Pull Request automatisch erstellen, wenn er die Genehmigungskriterien erfüllt. Ihr Team sollte entscheiden, wer Pull Requests wann zusammenführt.
Der Prozess Ihres Teams
Sobald Sie mit der Verwendung von Featurebranches und Pull Requests begonnen haben, kann sich der Prozess Ihres Teams in etwa wie folgt ändern:
Ein Teammitglied klont Ihr freigegebenes Repository.
Es nimmt lokale Änderungen an einem Branch in seiner eigenen lokalen Kopie des Repositorys vor.
Nach Abschluss der Änderungen pushen sie den lokalen Branch an das freigegebene Repository.
Innerhalb des freigegebenen Repositorys erstellen sie einen Pull Request, um den Branch mit dem Mainbranch (main) zusammenzuführen.
Andere Teammitglieder überprüfen die Änderungen. Wenn sie zufrieden sind, genehmigen sie den Pull Request, und er wird mit dem Mainbranch des freigegebenen Repositorys zusammengeführt.
Sie löschen die Branches im freigegebenen Repository und in ihrer lokalen Kopie des Repositorys.
In einigen Szenarios löst der Push des Remoterepositorys eine automatisierte Pipeline aus, um den Code zu überprüfen, zu testen und bereitzustellen. In anderen Microsoft Learn-Modulen erfahren Sie mehr über Pipelines.
Dieser überarbeitete Prozess wird im folgenden Diagramm veranschaulicht.
