Qu’est-ce qu’une requête pull ?

Une pull request (PR) est une méthode permettant de proposer des modifications à une base de code. Les développeurs logiciels placent le référentiel de code principal (également appelé référentiel) dans une branche distincte, valident le code dans cette branche pendant qu’ils travaillent et créent une requête pull pour signaler les modifications suggérées pour l'avis du code avant d’extraire ou de fusionner les modifications de la branche dans la base de code principale.

Les PR sont des mécanismes courants dans les référentiels Git tels que Bitbucket et GitHub. GitLab utilise le terme « merge request » au lieu de « pull request » pour désigner le même processus.

Les développeurs peuvent créer des pull requests en utilisant l’interface en ligne de commande (CLI) ou l’interface web. De nouvelles demandes d’extraction sont généralement ouvertes pour les correctifs, les mises à jour des dépendances, les nouvelles fonctionnalités ou le code remanié. Les pull requests simplifient les avis de code, maintiennent les bases de code à jour et favorisent la collaboration entre les membres des équipes de développement logiciel .

Les PR permettent aux développeurs d'élaborer le code source et de le tester localement. Comme les modifications de code sont isolées de la branche principale, les développeurs n'ont pas à craindre de casser l'ensemble de la base de code.

La méthodologie de pull request implique trois rôles essentiels qui s’appliquent principalement aux projets open source mais peuvent aussi être adoptés par des projets propriétaires ou fermés :

• Responsables de la maintenance : les responsables du projet gèrent (et souvent responsables) le projet et ont le pouvoir d’approuver et de fusionner les PR ou de les rejeter.

• Réviseurs : Ces membres de l'équipe (qui peuvent être des mainteneurs eux-mêmes ou d'autres contributeurs actifs ayant une grande expérience du projet) vérifient la qualité du code des modifications proposées et suggèrent des améliorations s'ils le jugent nécessaire.

• Contributeurs : Ces développeurs sont chargés d’apporter des modifications et d’ouvrir des demandes de fusion.

La création de demandes d’extraction implique généralement une procédure en sept étapes :

1. Un contributeur forke le dépôt principal pour créer une nouvelle branche (en utilisant la git checkout commande ou l’interface web) et clone cette branche vers leur machine locale.
   
   
2. Le contributeur travaille sur leurs modifications et transmet le code localement à la branche.
   
   
3. Une fois que le contributeur a terminé et testé son code, il extrait d'abord les dernières mises à jour du dépôt principal pour éviter toute modification contradictoire avant de publier son code.
   
   
4. Le contributeur ouvre une nouvelle demande d'extraction pour que les changements qu'il propose soient intégrés dans la branche principale.
   
   
5. Les évaluateurs reçoivent des notifications lorsque des demandes d’extraction sont Envoyer. Ils vérifient la PR pour comparer les différences (également appelées diffs) entre la branche du contributeur et la branche principale, en donnant leur avis sur le code et en commentant les zones qui nécessitent une optimisation ou une amélioration.
   
   
6. Les contributeurs font des commits supplémentaires en fonction des suggestions et des demandes de modification des réviseurs.
   
   
7. Lorsque tous les changements ont été mis en œuvre, le réviseur en informe le mainteneur, qui approuve la PR. La pull request est ensuite fusionnée dans le référentiel principal.

Les équipes de développement de logiciels peuvent choisir parmi un certain nombre d'options de workflows en fonction de leurs besoins. Voici les workflows de requêtes pull les plus courants :

• Workflow des branches de fonctionnalités

• Forking workflow

• git-flow

• Workflow empilé

Chaque nouvelle fonctionnalité a sa propre branche dédiée avec un nom descriptif pour mettre en évidence l'objectif de la fonctionnalité. Une fois la fonctionnalité terminée, les développeurs peuvent transférer la branche des fonctionnalités vers la branche principale et créer une pull request.

Ce workflow maintient la stabilité de la branche principale puisque les contributeurs travaillent séparément sur les fonctionnalités. Mais la gestion de plusieurs branches de fonctionnalités peut s'avérer difficile.

La procédure en sept étapes décrite dans la section précédente sur la création des pull requests correspond à un workflow. Les projets open source utilisent souvent ce workflow, qui complète également les pratiques d'intégration continueetde livraison continue (CI/CD). Le flux GitHub suit un processus similaire au workflow.

Vincent Driessen, ingénieur logiciel, a formulé git-flow en 2010. Il est généralement utilisé pour créer des logiciels avec des calendriers de publication rigoureux ou des logiciels prenant en charge plusieurs versions.

Ce workflow suit un modèle de branchement composé de ces branches :

• main contient la dernière version stable

• develop agit comme une branche d'Intégration pour les correctifs, fonctionnalités et autres modifications de code incluses dans la prochaine version

• feature utilise develop comme branche source et branche cible, les fonctionnalités étant fusionnées dans develop lorsqu'elles sont prêtes

• release est dérivé du développement et étiqueté avec le numéro de version de la prochaine version, puis fusionné dans les domaines du développement et de la main une fois qu’il est adapté à l’expédition

• hotfix est dérivé directement du main pour résoudre tous les problèmes de production prioritaires ou de gravité élevée, puis fusionné dans les domaines developer et main dès que les correctifs sont effectués

Les développeurs créent des demandes d'extraction pour les branches hotfix , feature et release qui ont besoin d'avis.

Un workflow empilé décompose les tâches volumineuses en une séquence de petites modifications incrémentielles du code. La prochaine modification du code dépend de la précédente, c'est pourquoi les demandes d'extraction sont construites les unes sur les autres.

Considérons une fonctionnalité qui implique des modifications de ces fonctions : la base de données ou le modèle de données, l’API et la front-end. Dans le workflow conventionnel de la branche de fonctionnalité ou du forking, un contributeur doit attendre que le PR soit examiné, approuvé et fusionné dans la branche principale avant de pouvoir commencer à mettre à jour l’API. Dans un workflow empilé, ce délai d’attente est éliminé : le contributeur peut partir de la base de données ou des modifications du modèle de données pour commencer à travailler sur l’API, envoyer une PR pour cela, et partir des modifications de l’API pour s’attaquer aux tâches front-end.

Les requêtes pull offrent les avantages suivants :

• Cultive la collaboration

• Améliore la qualité du code

• Améliore la transparence

• Renforce les compétences en matière de codage

Les pull requests favorisent la coopération en encourageant les membres de l'équipe à travailler ensemble, quel que soit leur rôle. Les relations publiques facilitent les commentaires et la façon de les traiter, déclenchent des discussions et suscitent des idées pour des améliorations.

Les PR donnent le coup d'envoi du processus de révision du code, en aidant à repérer les bogues, les écarts par rapport au style et aux normes de codage, les problèmes de performance et les vulnérabilités en matière de sécurité. Cette surveillance supplémentaire permet de maintenir, voire d'améliorer la qualité du code.

Les demandes d’extraction permettent aux équipes de voir quels changements ont été implémentés, qui les a effectués, où ils ont été appliqués et les raisons qui les ont motivées. Cette visibilité permet d'avoir de meilleures informations sur l'état de la base de code et du projet lui-même.

Les évaluateurs et les contributeurs peuvent apprendre les uns des autres, acquérir de nouvelles techniques en cours de route et découvrir de nouvelles approches des problèmes. Les débutants et les nouveaux membres de l'équipe peuvent également étudier les PR précédents pour mieux comprendre la base de code et se familiariser avec les normes de codage et les meilleures pratiques de l'équipe.

Bien que la création de demandes d’extraction puisse sembler simple, voici quelques astuces et conseils pour faciliter le processus :

• Examiner les brouillons

• Les détails comptent

• Gardez votre concentration

• Rester informé

• Prendre des modèles

Les brouillons de demandes d’extraction ou de fusion permettent aux développeurs de partager leurs travaux en cours. Cela permet aux membres de l’équipe de commencer les collaborations plus tôt et d’inviter les commentaires plus tôt afin que ceux qui sont bloqués sur un problème puissent trouver des solutions potentielles de leurs collègues.

Les développeurs doivent fournir des messages clairs, concis et précis pour leurs nouveaux commits. La clarté, la concision et la spécificité s'appliquent également aux titres et aux descriptions des relations publiques, ce qui permet aux réviseurs de comprendre plus facilement et plus rapidement l'intention des modifications de code.

Regrouper plusieurs problèmes dans une seule PR peut entraîner des délais d’examen plus longs et un plus grand nombre d'avis. Chaque requête d’extraction ne doit concerner qu’un seul correctif de bug ou une seule fonctionnalité. Les demandes de fusion ciblées peuvent conduire à des avis de code plus efficaces.

Avant de saisir du code et d'ouvrir un PR, les développeurs doivent s'assurer que leur branche est à jour. La détection des dernières modifications et des nouveaux commits permet d’éviter les conflits une fois la requête pull fusionnée. Ils peuvent utiliser soit la commande git pull pour récupérer et fusionner les modifications de la branche cible, soit la commande git rebase pour obtenir un historique des commits git.

Les modèles de description PR permettent de garantir la cohérence et fournissent un contexte essentile pour rationaliser les avis de code. Les équipes peuvent créer un modèle pour différents types de pull requests, comme des correctifs, des fonctionnalités ou du code refactoré.

Les modèles sont généralement rédigés à l'aide du langage de balisage Markdown et placés dans le dossier racine ou la branche principale du projet. Les champs typiques sont les suivants :

• Description du problème ou de la fonctionnalité (avec un lien vers le ticket correspondant dans Jira ou un autre logiciel de suivi des problèmes pour référence)

• Solution décrivant les modifications de code en détail

• les tests, tels que les tests unitaires ou les cas de Intégration, la couverture des tests et les étapes pour valider manuellement la solution si applicable

• Changements de configuration

• Liste des tâches pertinentes, telles que la documentation du code et la création de code propre, sans erreur ni avertissement

L’automatisation des PR peut accélérer le cycle de vie d’une requête d’extraction, de la création à la fusion, en passant par l'avis. L'automatisation des relations publiques englobe une couche de systèmes qui contribuent à réduire les goulots d'étranglement :

• PR empilées

• Pipelines CI/CD

• Systèmes de gestion SDLC

• Assistants de codage alimentés par l’IA

La plupart des dépôts Git ne sont pas conçus pour supporter un workflow empilé, mais certains outils simplifient la synchronisation des demandes de tirage empilées et la gestion des conflits de fusion. Ces outils comprennent la plateforme Graphite, qui dispose d'un CLI et d'une extension pour VS Code de Microsoft pour les PR empilés et d'une interface web pour les gérer ; le système de gestion du code source Sapling de Meta ; et le CLI open-source ghstack pour soumettre des diffs empilés à GitHub en tant que demandes d'extraction séparées.

En tant que workflow DevOps automatisé, le pipeline CI/CD contribue à garantir la qualité du code. Des plateformes telles que GitHub Actions et GitLab ainsi que d'autres outils de CI peuvent exécuter des tests unitaires et des tests d'intégration et déployer des environnements de prévisualisation qui servent de bacs à sable pour visualiser et tester les changements de code dans les PR.

Les pipelines CI/CD renforcent également les pratiques de codage sécurisé. Les analyseurs de code statique et autres outils de tests statiques de sécurité d'application (SAST) s'intègrent de façon fluide à la plupart des environnements CI/CD afin d'identifier les vulnérabilités probables du code. Les équipes DevOps peuvent implémenter des hooks de pré-commit pour la détection des secrets, faisant de l'analyse des secrets une étape obligatoire avant que les développeurs ne valident du code ou n'initient des demandes d'extraction, et bloquant les modifications contenant des secrets codés en dur.

Des plateformes telles que Jira et IBM® Engineering Lifecycle Management (ELM) permettent de suivre et de gérer les demandes de retrait tout au long du cycle de développement logiciel (SDLC).

Dans le cadre de la suite ELM, IBM Engineering Workflow Management (EWM) et IBM Engineering Integration Hub intègrent l'automatisation directement dans les workflows de développement. EWM peut se connecter aux dépôts Git via les connecteurs du Hub et déclencher la création de PR à partir des éléments de travail. Lorsqu'une exigence ou une demande de modification est approuvée dans EWM, une règle peut automatiquement ouvrir une pull request dans le dépôt Git lié et préremplir la description.

Les automatisations pilotées par Aldans ELM peuvent également exécuter des analyses statiques et des suites de tests une fois que la RP est ouverte, en renvoyant les résultats à l'élément de travail et en bloquant la fusion jusqu'à ce que les critères soient remplis. Pendant ce temps, le Hub synchronise l'état des RP à travers les outils, le reflétant dans le référentiel et les tableaux de bord EWM pour une visibilité en temps réel.

Des assistants de codage alimentés par l’IA comme GitHub Copilot et IBM Bob peuvent compléter les flux de travail des pull requests. Par exemple, Bob peut générer des messages de commit bien formatés et significatifs. Il examine le nom de la branche et l’historique des validations pour correspondre aux conventions de style d’un projet.

Bob peut également créer une demande d'extraction directement à partir de l'IDE d'un développeur. Il analyse le nom de la branche, les modifications de code et l’historique des commits afin de comprendre le but et la portée. Il génère ensuite un titre de PR et une description détaillée qui résume les changements, détectant automatiquement et utilisant les modèles de PR existants d’un projet pour les descriptions des pull requests.