Im Rahmen der Pull-Request-Prüfung müssen häufig zusätzlich zur Codeüberprüfung selbst eine Reihe von Routineprüfungen durchgeführt werden. Einige Überprüfungen betreffen möglicherweise das PR-Design. Andere - Überprüfen Sie die entsprechenden Bedingungen, die die Grundlage für den Änderungsprozess bilden.
Wenn Routineprüfungen nicht automatisiert werden, kann eine Person beginnen, sie zu vergessen oder zu umgehen. Weil Routine langweilig ist.
Visual Studio Team Services bietet eine recht komfortable Infrastruktur für die Bearbeitung von Pull-Anfragen. Dies umfasst Richtlinien für benutzerdefinierte Zusammenführungserstellungen, die Ernennung von Prüfern und Zusammenführungsregeln für akzeptierte Änderungen. All dies wird durch ein praktisches System zum Diskutieren und Kommentieren von Code ergänzt.
Das leistungsstärkste Tool zum Erweitern des Pull-Request-Prozesses sind externe Plug-In-Richtlinien.
Wir werden über ihre Erstellung und Verwendung sprechen (und den Code sehen).
Erweiterbare Pull-Anforderungsstatus
PR-Status sind im Kontext definierte Flags. Kontext - eine einzigartige Kombination aus dem Namen des Kontexts und dem "Genre". Das Genre ist normalerweise eines pro Anwendung, das den Status manipuliert.
Zum Beispiel:
Status 1: genre = 'my-policy', name = 'check-1'
Status 2: genre = 'my-policy', name = 'check-2'
Der Status nimmt einen der vordefinierten Werte an. Um den Prozess zu unterstützen, werden wir an zwei interessiert sein: erfolgreich und gescheitert.
Status können beim Einrichten einer Brunch-Richtlinie verwendet werden: Ausgewählte Flags müssen den Status erfolgreich haben, damit PR akzeptiert werden kann. Auf die gleiche Weise werden integrierte Richtlinien implementiert, die die Anzahl der Fahrer, das Vorhandensein eines angehängten Tickets usw. überprüfen.
Wechseln Sie zur Bearbeitung der Verzweigungsrichtlinie. Außenpolitik hinzufügen.
Wenn der Status mindestens einmal festgelegt wurde, ist er im Dropdown-Menü verfügbar.
Unten können Sie einen Titel für den Status angeben, der im Pull-Request-Abschlussblock angezeigt wird.
Hinzugefügte Status werden auf der Pull-Anforderungsseite im Prüfblock angezeigt:
Wenn der Status nicht als Richtlinie verwendet wird, wird sein Wert auf der Seite im Abschnitt Status angezeigt. Wenn der Status als Richtlinie angegeben ist, wird er oben im Block angezeigt.
Programmstatusverwaltung
PR-Status können mithilfe der REST-API programmgesteuert bearbeitet werden. Somit ist es möglich, zusätzliche PR-Prüfungen durchzuführen und deren Ergebnis direkt in den Änderungsprozess umzusetzen.
Der neue Statuswert wird von der Create- Methode hinzugefügt. Zusätzlich zum Ergebnis und Kontext ist es notwendig, den Text zu vermitteln, den der Benutzer sieht. Optional können Sie eine URL übergeben: In diesem Fall wird die Statusbezeichnung auf dem PR-Formular zu einem Link und der Benutzer kann zur Seite mit den Statusdetails wechseln.
Ein Methodenaufruf führt zur Erstellung eines neuen PR-Statusdatensatzes. Innerhalb eines Kontexts wird der zuletzt hinzugefügte Statuswert als aktiv betrachtet. Frühere Statuseinträge sind auf der Benutzeroberfläche nicht sichtbar, können jedoch mithilfe der List- Methode abgerufen werden.
Für den Status der Status im vorherigen Bild kann die tatsächliche Liste der Status für die Pull-Anforderung wie folgt lauten:
{ "value": [ { "id": 1, "state": "failed", "description": "PR title format", "context": "@{name=check-title; genre=my-pr-policy}", "creationDate": "2018-11-06T18:35:57.0324172Z", "updatedDate": "2018-11-06T18:35:57.0324172Z", "createdBy": "Masked value", "targetUrl": null }, { "id": 2, "state": "failed", "description": "Build for last update", "context": "@{name=check-build; genre=my-pr-policy}", "creationDate": "2018-11-06T18:35:57.5167963Z", "updatedDate": "2018-11-06T18:35:57.5167963Z", "createdBy": "Masked value", "targetUrl": null }, { "id": 3, "state": "succeeded", "description": "No offset from develop", "context": "@{name=check-offset; genre=my-pr-policy}", "creationDate": "2018-11-06T18:35:57.782379Z", "updatedDate": "2018-11-06T18:35:57.782379Z", "createdBy": "Masked value", "targetUrl": null }, { "id": 4, "state": "succeeded", "description": "PR title format", "context": "@{name=check-title; genre=my-pr-policy}", "creationDate": "2018-11-06T18:46:37.2627154Z", "updatedDate": "2018-11-06T18:46:37.2627154Z", "createdBy": "Masked value", "targetUrl": null }, { "id": 5, "state": "succeeded", "description": "Build for last update", "context": "@{name=check-build; genre=my-pr-policy}", "creationDate": "2018-11-06T18:51:33.7920543Z", "updatedDate": "2018-11-06T18:51:33.7920543Z", "createdBy": "Masked value", "targetUrl": null }, { "id": 6, "state": "failed", "description": "PR title format", "context": "@{name=check-title; genre=my-pr-policy}", "creationDate": "2018-11-06T18:53:44.3075889Z", "updatedDate": "2018-11-06T18:53:44.3075889Z", "createdBy": "Masked value", "targetUrl": null }, { "id": 7, "state": "failed", "description": "Title format is not correct", "context": "@{name=check-title; genre=my-pr-policy}", "creationDate": "2018-11-06T19:26:11.3019433Z", "updatedDate": "2018-11-06T19:26:11.3019433Z", "createdBy": "Masked value", "targetUrl": null } ], "count": 7 }
Nachdem Sie sich die Liste der aktuellen Status angesehen haben, können Sie den ausgewählten Status anhand des Index in der Liste aktualisieren. Verwenden Sie dazu die Update- Methode.
Schließlich können Statusdatensätze mit der Löschmethode gelöscht werden.
Eine Historie von PR-Statusänderungen kann für die weitere Analyse hilfreich sein. Daher verwenden wir die folgende Methode zum Ändern des Status:
- Suchen Sie den neuesten Statusdatensatz für denselben Kontext
- Wenn sie dieselben Ergebniswerte, Beschreibungen und Links hat, die wir hinzufügen möchten, tun wir nichts
- Andernfalls fügen Sie einen neuen Statusdatensatz hinzu.
Auf diese Weise können Sie eine Änderungshistorie führen, ohne sie stark aufzublähen.
function Set-PullRequestStatus { param( [Parameter (Mandatory = $true)] [string] $pullRequestId, [Parameter (Mandatory = $true)] [string] $state, [Parameter (Mandatory = $true)] [string] $description, [Parameter (Mandatory = $true)] [string] $contextName, [Parameter (Mandatory = $false)] [string] $contextGenre, [Parameter (Mandatory = $false)] [string] $targetUrl, [Parameter (Mandatory = $true)] [object] $context ) $b = @{ state = $state; description = $description; context = @{ name = $contextName; genre = $contextGenre; }; targetUrl = $targetUrl; } $body = ConvertTo-Json $b # # Get current list of statuses # $endpoint = (Get-ProjectBaseURL) + "/_apis/git/repositories/{repositoryId}/pullRequests/{pullRequestId}/statuses?api-version=4.1-preview.1" $res = Get-AzureRequestReqults -URI $endpoint -context ($context + @{pullRequestId = $pullRequestId}) # # Try to find a status for a given context genre and name. Start looking from the last one. If found - check if it has same values. # $i = $res.count $foundSameStatus = $false while ($i -GT 0) { $r = $res.value[$i-1] if (($r.context.name -EQ $contextName) -AND ($r.context.genre -EQ $contextGenre)) { $foundSameStatus = ($r.state -EQ $state) -AND ($r.description -EQ $description) -AND ($r.targetUrl -EQ $targetUrl) break } $i-- } $res = $r # # If same status / values was not found - add new record. # if (-not $foundSameStatus) { $endpoint = (Get-ProjectBaseURL) + "/_apis/git/repositories/{repositoryId}/pullRequests/{pullRequestId}/statuses?api-version=4.1-preview.1" $res = Get-AzureRequestReqults -URI $endpoint -context ($context + @{pullRequestId = $pullRequestId}) -method POST -query $body } return @{status = $res; status_changed = $(-not $foundSameStatus)} }
Praktische Anwendung
Wir haben einen eher konservativen Ansatz gewählt, um Änderungen in der Integrationsbranche zu akzeptieren. Wir versuchen, die Änderung auf das Maximum im Feature-Zweig auf das Maximum zu testen.
Hier sind einige der Aufgaben, die wir mithilfe von PR-Status im Rahmen benutzerdefinierter Richtlinien lösen:
- Alle PRs müssen im gleichen Stil dekoriert sein. Daher ist das erste Steuerelement, das erstellt wurde, das Design des PR-Headers. Wir vergleichen es mit dem regulären Ausdruck.
- Der PR-Zweig sollte nicht hinter dem Zweig zurückbleiben, in den er gegossen wird (Integration wird durchgeführt).
- Wenn im Rahmen von PR die Datenbankprojektdateien geändert werden, müssen auch Autotest-Dateien vorhanden sein.
- Es gibt eine erfolgreiche Montage der Niederlassung für die letzte Änderung.
- Diese Baugruppe wurde erfolgreich auf den Prüfstand gepumpt und Autotests bestanden.
Die aufgeführten Bedingungen können manuell überprüft werden. Wir haben das schon mal gemacht. Dies ist jedoch eine Routine und wurde durch einen automatisierten Prozess ersetzt. Jetzt können wir die Überprüfungen ergänzen und ändern - sie werden immer in den Prozess integriert und immer ausgeführt.
Ein weiteres großes Plus an Richtlinien - sie sind für alle transparent und immer in Sicht - auf der PR-Seite. Sie müssen nicht mehr erinnert werden.
Darüber hinaus zeigen wir für Richtlinien, deren Überprüfung fehlschlägt, einen Link zu unseren Wiki-Seiten mit einer Beschreibung der Richtlinie und der erwarteten Aktionen an.
Technische Umsetzung der Durchsetzung von Richtlinien
Derzeit ist die Richtlinienlogik in Form von Powershell-Skripten implementiert. Aufgrund der Cmdlets auf hoher Ebene und eines guten Objektdatenmodells ist der Skriptcode sehr kompakt. Die Möglichkeit, das Skript in Schritten interaktiv auszuführen und Variablen zu basteln, vereinfacht den Entwicklungs- und Debugging-Prozess erheblich.
Übrigens können nach der Veröffentlichung von Powershell Core-Skripten auf anderen Plattformen (unter MacOS getestet) ausgeführt werden.
Führen Sie die Skripte in einer speziellen Version von VSTS nach einem Zeitplan etwa alle paar Stunden aus. Vielleicht rennen wir öfter durch den Schuppen.
Dieser Ansatz bietet natürlich eine deutlich langsamere Antwort als wenn Sie dieselbe in Form einer Azure-Funktion implementieren und über einen Web-Hook mit VSTS verbinden. Für uns war es jedoch wichtiger, Überprüfungen durchzuführen und zu sehen, wie dies im Prozess (MVP) funktioniert. Die Effizienz der Überprüfung ist noch nicht wichtig. Dies wird der nächste Schritt sein.
Die Implementierung von Bibliotheken für die Arbeit mit der VSTS-REST-API, die für Überprüfungen verwendet werden, sowie ein kleines Beispiel, das einige dieser Richtlinien implementiert, finden Sie im Repository auf GitHub . Ich hoffe, jemand wird es nützlich finden.