Comment configurer une demande d'extraction dans Azure DevOps

Lorsqu'il y a plusieurs développeurs sur le même projet, vous devez fusionner votre code en une seule branche. Avant de faire cela, il est important de s'assurer que la nouvelle fonctionnalité que vous venez de créer est correctement construite. Pour vérifier, vous devez proposer votre code sous forme de pull request. Je vais expliquer pourquoi les pull request sont importants et comment les configurer via Azure DevOps.

Qu'est-ce qu'une pull request ?

Une pull request (PR) est plus qu'une simple notification— c'est un forum dédié pour discuter de la fonctionnalité proposée. S'il y a des problèmes avec les modifications, les coéquipiers peuvent publier des commentaires dans la demande d'extraction et même ajuster la fonctionnalité en poussant des commits de suivi, ce qui vous permet d'enregistrer vos modifications dans le référentiel. Toute cette activité est suivie directement à l'intérieur du PR.

Pourquoi devriez-vous faire une demande de tirage

Pour construire un bon projet avec votre équipe, chaque développeur doit comprendre comment le projet est structuré et quel est le reste du code le fait.

Un PR est utile dans cette situation pour les raisons suivantes :

• Il garantit que les membres de votre équipe connaissent des parties du code qu'ils n'ont pas écrites.
• Les développeurs peuvent apprendre les uns des autres.
• Évite une mauvaise implémentation de l'architecture.
• Améliore le code au fur et à mesure que le projet progresse.
• Détecte tôt les bogues potentiels.

Comment configurer une demande de tirage dans Azure

Azure DevOps a une interface vraiment intéressante pour soumettre un PR. La configuration des stratégies pour une branche spécifique peut être effectuée facilement. Accédez à Azure DevOps dans la section "Repos", recherchez la section "Branches", puis cliquez sur les 3 points de votre branche de référence pour configurer les stratégies.

Les réviseurs

Les personnes qui effectuent la vérification, à l'exception de l'auteur, sont appelées « revieweurs ». Premièrement, il est recommandé de demander plusieurs examinateurs. Un minimum de 1 critique est nécessaire, mais si vous en avez 2, c'est encore mieux. Vous devrez également désactiver la possibilité d'approuver automatiquement votre travail car, si vous ne le faites pas, le PR ne fonctionnera pas. N'oubliez pas que l'objectif est de donner aux autres développeurs la possibilité de vérifier votre code avant qu'il ne soit fusionné avec le reste du projet.

Pour laisser les réviseurs, vérifier le code et comprendre ce qui a été fait, encore plus , vous devez demander des éléments de travail liés, car cela évite également d'ajouter du code qui ne correspond pas exactement à la user story ou à la tâche associée.

Les réviseurs ont la possibilité d'« approuver », « approuver avec des suggestions », « attendre l'auteur » ou « rejeter », qui est directement visible avec un petit badge.

Si votre projet en a besoin, vous pouvez également fournir une liste de réviseurs qui seront automatiquement avertis lorsqu'un nouveau pull demande est créée, cela peut être intéressant pour l'architecte ou le responsable technique du projet par exemple :

Les commentaires

Si des commentaires ont été faits après avoir examiné un PR, il est important de vérifier s'ils ont été vus par le développeur avant de le fermer. En cochant la case de résolution des commentaires, vous pouvez vous assurer qu'ils seront visibles.

Si tous les commentaires ne sont pas définis sur « résoudre », le PR ne peut pas être fusionné avec le reste du code. Les commentaires sont un bon moyen de communiquer entre développeurs, et vous pouvez également taguer quelqu'un pour attirer son attention sur un point précis.

Créer le projet

Pour être sûr que le projet n'est pas seulement intégré à la machine du développeur, il est judicieux d'ajouter une validation de build à l'aide des pipelines Azure DevOps. C'est facile si vous en avez déjà créé un. Cliquez sur « validation de compilation » et sélectionnez le pipeline que vous souhaitez exécuter :

Dans ce cas, le nom du pipeline est « POCproject ».

Considérez l'exemple suivant :

An MS tailspin est composé d'un projet .NET, NPM et MS Unit Tests. Vous allez d'abord construire le projet sur un serveur de développement, puis vous devez tester et mettre en scène si l'une de ces 3 étapes a échoué. Votre PR ne pourra pas s'exécuter et le code ne fusionnera pas. C'est un bon moyen d'éviter d'intégrer du code qui ne se compile pas avec le reste du projet.

Utilisez les demandes de tirage à tout moment

C'est tout ! J'espère que vous pourrez utiliser ces connaissances pour implémenter une revue de code parfaite dans votre portail Azure DevOps. Chaque projet est différent et il n'y a pas d'autre moyen que d'expérimenter, de tirer des conclusions, d'améliorer et d'expérimenter à nouveau. Pour plus d'informations, contactez nos experts dès aujourd'hui.

À propos de l'auteur

Ingénieur DevOps qualifié avec de nombreuses années d'expérience pratique dans la prise en charge, l'automatisation et l'optimisation des déploiements critiques dans Azure DevOps, Jenkins , et AEM tirant parti de la gestion de la configuration, des processus CI/CD et DevOps.

En savoir plus sur cet auteur