Combien d’onglets sont ouverts à côté de la pull request ?
Imaginez que vous vous occupiez d’une nouvelle issue dans le parcours d’onboarding de l’essai gratuit de votre produit : rendez l’étape « invite your teammates » facultative. À mesure que les inscriptions augmentent, l’équipe support continue de signaler cette étape comme un point de friction. Un gain rapide, n’est-ce pas ?
De la définition du périmètre au déploiement, vous avez besoin de répondre à ces quatre questions :
S’agit-il vraiment de la bonne modification ?
Les dépendances auxquelles je touche sont-elles propres ?
Comment la mettre en production en toute sécurité ?
Est-il sûr de procéder au déploiement maintenant ?
Chaque réponse se trouve dans un outil différent ; travailler sur une pull request revient donc à transporter le même contexte entre quatre endroits différents.
Les applications agent de GitHub mettent les outils dont vous avez besoin pour répondre à ces questions là où vous travaillez déjà, en s’appuyant sur la même plateforme et le même harness que notre propre Copilot cloud agent.
L’exemple ci-dessous montre comment utiliser des services dont vous dépendez déjà, comme Amplitude, Endor Labs, LaunchDarkly et PagerDuty, pour répondre à ces questions et mener cette demande à bien sans jamais quitter GitHub.
1. Avant de commencer le développement
L’équipe support affirme que l’étape « invite your teammates » est agaçante pour les clients qui commencent le parcours d’onboarding de votre produit ; elle ne vous a toutefois fourni aucune information sur les personnes qui se plaignent ni sur le fait que ces plaintes entraînent ou non une perte de clients. Vous avez raison d’être sceptique. Au lieu d’ouvrir Amplitude et de créer une requête pour vérifier votre hypothèse, vous posez directement la question à l’agent Amplitude depuis l’onglet Agents :
@amplitude[agent] L’achèvement de l’étape d’invitation de l’équipe est-il associé à la réussite aux étapes suivantes de l’entonnoir ? Ventile selon les segments que nous mesurons.
La distinction est nette : les utilisateurs en équipe qui terminent l’étape ont ensuite davantage de chances d’être conservés, tandis qu’il n’existe pas de telle relation pour les utilisateurs seuls. Nous avons désormais une raison de redéfinir le périmètre : reportez cette étape pour les personnes qui s’inscrivent seules, mais maintenez-la pour les équipes.
Les insights produit sont désormais accessibles dans GitHub, ce qui permet de corriger l’orientation avant même d’écrire du code.
2. Pendant le développement
Copilot ouvre une pull request préliminaire pour la modification. L’application met également à jour les dépendances utilisées dans le parcours d’onboarding. Plutôt que d’attendre l’échec d’une analyse CI, vous demandez à l’agent Endor Labs dans un commentaire :
@endor-labs-github-agenthq[agent] Y a-t-il quelque chose auquel je dois faire attention dans les dépendances concernées par cette pull request ?
L’agent identifie les dépendances modifiées, les vérifie à la recherche de vulnérabilités connues et de risques plus larges liés aux paquets, puis présente son rapport dans la pull request. Cette fois, tout semble propre. Rien ne doit être corrigé.
L’examen des dépendances devient un contrôle proactif alors que la modification est encore devant vous. C’est bien mieux que d’apporter une correction après l’échec d’une analyse CI.
3. Mise en production
La constatation précédente est désormais mise en pratique : les personnes qui s’inscrivent seules utilisent le parcours facultatif, tandis que les équipes conservent le parcours actuel. Comme ces segments sont déterminés lors de l’inscription, un feature flag peut les cibler directement. Demandez à l’agent LaunchDarkly de le configurer pour vous, comme vous le feriez avec un coéquipier :
@launchdarkly-agent[agent] veuillez créer un feature flag pour cette pull request et le relier au code.
– key: defer-team-invite
– type: boolean
– default: false
– target: solo-intent signups
– rollout: internal > 5% > 25% > 100%
L’agent crée le feature flag dans LaunchDarkly et ajoute l’implémentation du code sous forme d’un commit pour que vous l’examiniez. Si l’environnement cible nécessite une approbation, il crée une demande d’approbation au lieu d’appliquer directement la modification du ciblage. Un humain décide toujours si le déploiement doit se poursuivre.
La configuration du feature flag n’est plus un processus nécessitant un deuxième outil, un transfert manuel du code et une coordination sur Slack : elle se résume à un commentaire de pull request et à un commit à examiner.
4. Avant la mise en production
L’examen indique que le code est correct ; toutefois, savoir si le service est en bon état pour un déploiement est une question différente.