Souvent, dans le cadre de la vérification de la demande d'extraction, en plus de la révision du code elle-même, il est nécessaire d'effectuer un ensemble de vérifications de routine. Certains contrôles peuvent concerner la conception du PR. Autres - vérifiez les conditions connexes qui constituent la base du processus d'adoption des modifications.
Si les contrôles de routine ne sont pas automatisés, une personne peut commencer à les oublier ou à les contourner. Parce que la routine est ennuyeuse.
Visual Studio Team Services offre une infrastructure assez pratique pour gérer la requête Pull. Cela inclut les politiques de génération de fusion personnalisées, la nomination des réviseurs, les règles de fusion pour les modifications acceptées. Tout cela est complété par un système pratique pour discuter et commenter le code.
L'outil le plus puissant pour étendre le processus Pull Request est les stratégies de plug-in externes.
Nous allons parler de leur création et de leur utilisation (et voir le code)
États extensibles de demande d'extraction
Les états PR sont des indicateurs définis dans le contexte. Contexte - une combinaison unique du nom du contexte et du "genre". Le genre est généralement un par application qui manipule le statut.
Par exemple:
Statut 1: genre = 'my-policy', name = 'check-1'
Statut 2: genre = 'my-policy', name = 'check-2'
Le statut prend l'une des valeurs prédéfinies. Afin de soutenir le processus, nous nous intéresserons à deux: réussi et échoué.
Les statuts peuvent être utilisés lors de la configuration d'une politique de brunch: les drapeaux sélectionnés doivent avoir un statut réussi pour que PR soit accepté. De la même manière, des politiques intégrées sont mises en œuvre qui vérifient le nombre de conducteurs, la présence d'un ticket attaché, etc.
Accédez à la modification de la stratégie de branche. Ajoutez la politique étrangère.
Si l'état a été défini au moins une fois, il sera disponible dans le menu déroulant.
En bas, vous pouvez spécifier un titre pour le statut, comment il sera affiché dans le bloc d'achèvement de la demande d'extraction.
Les statuts ajoutés seront visibles sur la page de demande d'extraction dans le bloc de vérification:
Si le statut n'est pas utilisé comme stratégie, sa valeur s'affiche sur la page de la section Statut. Si le statut est spécifié en tant que stratégie, il sera visible en haut du bloc.
Gestion de l'état du programme
Les états PR peuvent être manipulés par programme à l'aide de l'API REST. Ainsi, il est possible de mettre en œuvre des vérifications RP supplémentaires et de traduire leur résultat directement dans le processus de modification.
La nouvelle valeur d'état est ajoutée par la méthode Create . En plus du résultat et du contexte, il est nécessaire de transmettre le texte que l'utilisateur voit. Vous pouvez éventuellement transmettre une URL: dans ce cas, l'étiquette d'état sur le formulaire PR deviendra un lien et l'utilisateur pourra accéder à la page avec les détails de l'état.
Un appel de méthode entraîne la création d'un nouvel enregistrement d'état PR. Dans un contexte, la dernière valeur d'état ajoutée est considérée comme active. Les entrées d'état antérieures ne sont pas visibles depuis l'interface utilisateur, mais elles peuvent être obtenues à l'aide de la méthode List .
Pour le statut des statuts de l'image précédente, la liste réelle des statuts de la demande d'extraction peut être la suivante:
{ "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 }
Après avoir consulté la liste des statuts actuels, vous pouvez mettre à jour celui sélectionné par index dans la liste. Pour ce faire, utilisez la méthode Update .
Enfin, les enregistrements d'état peuvent être supprimés à l'aide de la méthode Delete .
Un historique des changements de statut PR peut être utile pour une analyse plus approfondie. Par conséquent, nous utilisons la méthode suivante pour modifier les statuts:
- Rechercher le dernier enregistrement d'état pour le même contexte
- Si elle a les mêmes valeurs de résultat, descriptions et liens que nous voulons ajouter, nous ne faisons rien
- Sinon, ajoutez un nouvel enregistrement d'état.
Cela vous permet de conserver un historique des changements sans trop le gonfler.
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)} }
Application pratique
Nous avons adopté une approche plutôt conservatrice pour accepter les modifications de la branche d'intégration. Nous essayons de tester le changement au maximum sur la branche de fonctionnalité au maximum.
Voici quelques-unes des tâches que nous résolvons à l'aide des statuts PR, dans le cadre de stratégies personnalisées:
- Tous les RP doivent être décorés dans le même style. Par conséquent, le premier contrôle qui a été créé est la conception de l'en-tête PR. Nous le vérifions par rapport à l'expression régulière.
- La branche PR ne doit pas être à la traîne de la branche où elle est versée (l'intégration est réalisée).
- Si, dans le cadre de PR, les fichiers du projet de base de données sont modifiés, des fichiers d'autotest doivent également être présents.
- L'assemblage de la branche a réussi pour le dernier changement.
- Cet ensemble a été pompé avec succès vers le banc d'essai et les tests automatiques ont été réussis.
Les conditions répertoriées peuvent être vérifiées manuellement. Nous l'avons fait avant. Mais c'est une routine, et elle a été remplacée par un processus automatisé. Nous pouvons maintenant compléter et modifier l'ensemble de contrôles - il sera toujours intégré au processus, toujours exécuté.
Un énorme plus supplémentaire de politiques - elles sont transparentes pour tout le monde, et toujours en vue - sur la page PR. Ils n'ont plus besoin d'être rappelés.
De plus, pour les politiques qui échouent à la vérification, nous affichons un lien vers nos pages Wiki avec des descriptions des politiques et des actions attendues.
Mise en œuvre technique de l'application des politiques
Actuellement, la logique de stratégie est implémentée sous la forme de scripts PowerShell. En raison des applets de commande de haut niveau et d'un bon modèle de données d'objet, le code de script est très compact. Et la possibilité d'exécuter le script de manière interactive par étapes et de bricoler avec des variables rend le processus de développement et de débogage beaucoup plus facile.
Soit dit en passant, après la sortie du noyau PowerShell, les scripts peuvent être exécutés sur d'autres plates-formes (testés sur MacOS).
Exécutez les scripts dans une version spéciale de VSTS selon un programme environ une fois toutes les deux heures. Peut-être que nous commencerons à parcourir le sheduler plus souvent.
Cette approche, bien sûr, donne une réponse beaucoup plus lente que si vous implémentez la même sous la forme d'Azure Function et que vous la connectez à VSTS via un hook Web. Mais pour nous, il était plus important de mettre en œuvre des vérifications et de voir comment cela fonctionnerait dans le processus (MVP). L'efficacité de la vérification n'est pas encore importante. Ce sera la prochaine étape.
L'implémentation de bibliothèques pour travailler avec l'API RST VSTS, qui sont utilisées dans les vérifications, ainsi qu'un petit exemple qui implémente certaines de ces politiques se trouvent dans le référentiel sur GitHub . J'espère que quelqu'un le trouvera utile.