Déployer des demandes de tirage empilées dans votre organisation

Les demandes de tirage empilées permettent aux développeurs d’interrompre les modifications importantes dans une chaîne de petites demandes de tirage ciblées qui s’appuient les unes sur les autres. Cette approche peut aider votre organisation à maintenir la qualité de révision, car les développeurs produisent davantage de code, notamment avec Copilot et d’autres agents de codage.

Les demandes de tirage empilées ne nécessitent aucune configuration ni activation. Si votre équipe utilise déjà des demandes de tirage, elle peut créer une pile aujourd’hui. Les étapes ci-dessous vous aident à préparer vos contrôles existants et à prendre en charge un déploiement fluide, et non à activer une fonctionnalité.

Ce tutoriel vous aide à déterminer si les demandes de tirage empilées correspondent à votre organisation, assurez-vous que les fondations sont en place, pilotez le flux de travail, prenez en charge l’adoption et mettez à jour les outils programmatiques. Pour une compréhension fondamentale des demandes de tirage empilées, consultez À propos des demandes de tirage empilées.

1. Déterminez si les demandes de tirage empilées sont adaptées

Utilisez cette auto-vérification rapide avant d’investir dans un déploiement :

• Vos équipes produisent-elles un volume élevé de code, soit avec eux-mêmes, soit avec Copilot d’autres agents de codage ?
• Vos équipes travaillent-elles sur de grandes fonctionnalités, en particulier à l’intérieur de monorepos, qui sont difficiles à fractionner en demandes de tirage indépendantes ?

Si l’une ou l’autre décrit vos équipes, les demandes de tirage empilées peuvent les aider à soumettre des modifications dépendantes en unités plus petites sans attendre la fusion de chaque demande de tirage avant de commencer la suivante, tant que leur travail correspond à une contrainte : chaque demande de tirage dans une pile doit se trouver dans le même référentiel, en suivant une seule chaîne linéaire de branches. Les piles ne peuvent pas inclure de forks ou de structures de branchement, de sorte que les équipes qui s’appuient fortement sur des forks pour les contributions doivent conserver ces contributions en dehors des piles pour l’instant.

2. Assurez-vous que les fondations sont en place

Chaque demande de tirage dans une pile est évaluée par rapport à la base de la pile (généralement main), au lieu de la branche qu’elle cible directement. Vos règles ou ensembles de règles de branche existants et les flux de travail CI s’appliquent automatiquement :

• Les révisions requises, les vérifications d’état requises et CODEOWNERS sont toutes appliquées à la branche de base de la pile pour chaque demande de tirage dans la pile.
• Flux GitHub Actions de travail qui se déclenche sur pull_request les événements ciblant la branche par défaut d’un référentiel s’exécute pour chaque demande de tirage dans la pile, de sorte que votre configuration CI existante n’a pas besoin de changer.
• Les métadonnées de pile sont disponibles dans les expressions de flux de travail via github.event.pull_request.stack, si vous souhaitez personnaliser le comportement du flux de travail spécifiquement pour les demandes de tirage empilées. Étant donné qu’un flux de travail s’exécute une fois par demande de tirage dans une pile, les équipes peuvent utiliser ces métadonnées pour limiter les travaux coûteux et réduire l’utilisation de l’intégration continue. Pour plus d’informations, consultez Optimisation de l’intégration continue pour les demandes de tirage empilées.

Un ajout facultatif mérite d’être pris en compte : si les développeurs doivent réorganiser les demandes de tirage après avoir créé une pile sans la résoudre, adoptez l’extension gh stack pour GitHub CLI. La réorganisation sur place nécessite gh stack modify; sur le GitHub site web, les développeurs doivent décompresser les demandes de tirage et recréer la pile dans l’ordre souhaité.

Une pile se ferme également automatiquement une fois chaque demande de tirage qu’elle a fusionnée. Si une équipe ajoute de nouvelles branches au-dessus d’une pile fusionnée et s’exécute gh stack submit, l’interface CLI démarre une nouvelle pile avec la même branche de base. Il n’étend pas l’original. Les équipes qui souhaitent continuer à travailler sur un ensemble de modifications doivent planifier l’ouverture de la pile jusqu’à ce que tout le travail soit terminé.

Pour obtenir la liste complète des règles et exigences, consultez Demandes de tirage empilées.

3. Pilote avec un petit groupe

Choisissez un petit groupe de développeurs qui produisent un volume élevé de code, soit eux-mêmes, soit par le biais Copilot d’autres agents de codage. Demandez au groupe d’utiliser une fonctionnalité réelle et représentative pour le pilote au lieu d’un exemple jetable.

Pour créer leur première pile, dirigez les personnes vers Démarrage rapide pour les demandes de tirage empilées. Après le pilote, rassemblez des commentaires des développeurs et des réviseurs sur :

• Comment la planification de pile s’adapte à leur flux de travail existant et indique si les développeurs ont besoin d’une réorganisation sur place, ce qui nécessite l’extension gh stack 
• Indique si le flux de révision était différent maintenant que chaque demande de tirage dans la pile comporte ses propres révisions requises et vérifications d’état
• Toutes les lacunes de support ou de documentation qu’elles ont rencontrées

4. Déployer et prendre en charge l’adoption

Après le pilote, partagez des conseils quotidiens sur la création, la révision, la gestion et la fusion de piles avec les équipes : Demandes de tirage empilées.

Comme indiqué à l’étape 2, recommandez l’extension gh stackGitHub CLI lorsque les développeurs doivent réorganiser une pile sans la résoudre. Les équipes qui n’utilisent pas d’outils CLI locaux peuvent décompresser et recréer la pile dans l’ordre souhaité sur le GitHub site web.

Les équipes produisant un volume élevé de code généré par l’IA, l’un des signaux d’ajustement de l’étape 1, peuvent trouver des conseils sur l’empilement des modifications des agents de codage dans Code généré par l’IA stack dans les demandes de tirage.

5. Mettre à jour vos outils programmatiques

Pour soutenir l’adoption, passez en revue les outils internes, les bots ou les tableaux de bord qui créent, fusionnent ou effectuent le suivi des demandes de tirage par programmation, puis mettez-les à jour pour prendre en compte les piles.

Si votre organisation fournit une interface CLI interne ou d’autres outils de développement, vous pouvez utiliser l’API Stacks pour intégrer la création et la gestion de pile à ces outils existants au lieu de demander aux développeurs d’adopter gh stack.

Vous pouvez également suivre l’activité de pile par programme, par exemple, entre les tableaux de bord, les bots ou les outils internes.

• API REST : chaque demande de tirage retournée par l’API inclut un stack objet lorsqu’elle appartient à une pile, affichant le nombre, la taille de la pile, la position de la demande de tirage dans celle-ci et la branche de base de la pile. Une API Stacks dédiée (GET /repos/{owner}/{repo}/stacks) répertorie également chaque pile d’un référentiel ou la pile spécifique contenant une demande de tirage donnée. Consultez « API de demandes de tirage empilées et webhooks ».
• Webhooks : la pull_request charge utile du webhook inclut le même stack objet chaque fois qu’une demande de tirage appartient à une pile. Une action dédiée stacked se déclenche lorsqu’une demande de tirage est ajoutée pour la première fois à une pile, ce qui vous permet de réagir au moment où une pile se forme.

Dans les deux cas, le stack champ est null destiné aux demandes de tirage autonomes, de sorte que les intégrations existantes qui ne s’attendent pas à ce que les piles continuent de fonctionner de façon inchangée.