Prise en main des problèmes GitHub

  • 8 minutes

GitHub Issues est le système de suivi intégré pour les tâches, les bogues et les demandes de fonctionnalités dans les référentiels GitHub. Avant de pouvoir résoudre efficacement les problèmes à l’aide de GitHub Copilot, vous devez comprendre comment utiliser efficacement les problèmes GitHub.

Qu’est-ce que les problèmes GitHub ?

GitHub Issues fournit un espace de travail collaboratif où les équipes effectuent le suivi des éléments de travail, documentent les problèmes et les améliorations du plan. Chaque problème fonctionne comme un ticket dans un système de suivi : il peut être affecté aux membres de l’équipe, classés avec des étiquettes, liés aux modifications de code et enrichis par des discussions et de la documentation.

Considérez GitHub Issues comme une liste de to-do intelligentes d’une équipe. Chaque élément contient des discussions, des références de code et des métadonnées pour garantir que le travail ne soit pas négligé. Pour le travail axé sur la sécurité, GitHub Issues offre une visibilité et une traçabilité qui aident les équipes à répondre systématiquement aux vulnérabilités.

Composants principaux d’un problème

La compréhension de la structure des problèmes GitHub vous permet de lire, de gérer et de résoudre efficacement ces problèmes.

Titre

Le titre doit être un résumé concis et descriptif du problème. De bons titres aident les membres de l’équipe à comprendre rapidement le problème d'un seul coup d'œil.

Exemples de titres de problème efficaces :

  • « Vulnérabilité d’injection SQL dans le point de terminaison de recherche de produit »
  • « Chiffrement faible dans le stockage de mot de passe utilisateur »
  • « Risque de traversée de chemin d’accès dans la fonctionnalité de chargement de fichiers »

Un titre bien écrit communique immédiatement le type de problème (vulnérabilité de sécurité) et son emplacement (point de terminaison de recherche de produit).

Descriptif

La description est l’endroit où se trouvent les détails. Une description complète du problème doit inclure les informations suivantes :

  • Ce qui se passe : explication claire du problème ou de l’exigence.
  • Étapes à reproduire : pour les bogues, actions spécifiques qui déclenchent le problème.
  • Comportement attendu : Qu’est-ce qui doit se produire à la place ?
  • Pourquoi cela est important : l’importance de résoudre ce problème.
  • Critères d’acceptation : Comment vérifier quand le problème est résolu.

Voici un exemple de description d’un problème de sécurité bien structuré :

The login authentication function stores user passwords in plaintext in the database.

**Current behavior:**
Passwords are stored directly as strings without hashing or encryption.

**Security impact:**
If the database is compromised, all user passwords are immediately exposed.

**Expected behavior:**
Passwords should be hashed using a secure algorithm (like bcrypt) with appropriate salt before storage.

**Acceptance criteria:**
- Implement bcrypt password hashing.
- Verify no plaintext passwords exist in storage.
- Update authentication to validate against hashed passwords.

Un problème bien écrit est résolu à moitié. Il guide le développeur directement au problème sans ambiguïté.

Commentaires

La section commentaires active la discussion d’équipe. Les membres de l’équipe peuvent :

  • Posez des questions de clarification.
  • Proposer des solutions potentielles.
  • Partagez les résultats de l’enquête.
  • Consultez le code ou les questions connexes.
  • Documentez les décisions prises lors de la résolution.

Les commentaires créent une piste de connaissances qui aide les développeurs actuels et futurs à comprendre le problème et le raisonnement derrière la solution.

Personnes responsables

Le bénéficiaire est la personne responsable de la résolution du problème. Disposer d’un responsable clairement défini garantit la responsabilité et empêche les problèmes de stagner dans le backlog.

Bonne pratique : attribuez toujours un propriétaire principal pour un problème. Si vous êtes le destinataire, vous êtes responsable de mener à bien sa résolution. Être le bénéficiaire ne signifie pas que vous travaillez seul , vous pouvez collaborer avec d’autres personnes, mais vous êtes propriétaire du résultat.

Étiquettes

Les étiquettes catégorisent et hiérarchisent les problèmes. Les étiquettes courantes sont les suivantes :

  • Étiquettes de type : bogue, amélioration, documentation, sécurité.
  • Étiquettes de priorité : P0-critical, P1-high, P2-medium, P3-low.
  • Étiquettes d’état : en cours, bloquées et révision des besoins.
  • Étiquettes de composant : back-end, front-end, API, base de données.

Les étiquettes peuvent être utilisées pour filtrer et trier les problèmes dans les listes, ce qui facilite la mise en place d’un travail de haute priorité ou de sécurité.

Pour les problèmes de sécurité, les étiquettes aident les équipes à filtrer et hiérarchiser rapidement les vulnérabilités qui nécessitent une attention immédiate. Une étiquette de sécurité combinée avec P0-critiques indique que le problème nécessite une action urgente.

Étapes majeures

Les jalons regroupent les problèmes liés à un objectif commun. Par exemple, une version ou une phase de projet. Bien qu’il ne soit pas essentiel pour la résolution des problèmes individuels, les jalons aident les équipes à coordonner le travail et à suivre la progression vers des objectifs plus importants.

Examiner le cycle de vie d’un problème

Les problèmes passent de plusieurs étapes de la création à la résolution. Comprendre ce cycle de vie vous aide à gérer efficacement les problèmes.

Étape 1 : Création

Les problèmes peuvent être créés par les développeurs, les testeurs ou les utilisateurs qui identifient des problèmes ou des opportunités d’amélioration. Les problèmes de sécurité peuvent être découverts via :

  • Révisions de code.
  • Analyses de sécurité automatisées.
  • Test d’intrusion.
  • Rapports utilisateur.
  • Audits de sécurité.

Lors de la création d’un problème, incluez suffisamment de contexte et de critères d’acceptation. Cela définit des attentes claires lorsque le problème est considéré comme résolu.

Étape 2 : Triage

Pendant le triage, un responsable d’équipe ou une personne désignée :

  • Passe en revue les nouveaux problèmes.
  • Affecte des niveaux de priorité.
  • Ajoute les étiquettes appropriées.
  • Affecte le problème à un développeur.
  • Liens liés aux problèmes ou à la documentation.

Les problèmes de gravité élevée, en particulier les vulnérabilités de sécurité, sont signalés pour une attention immédiate. Les problèmes de sécurité ne doivent jamais rester dans le backlog sans être évalués.

Étape 3 : Examen et discussion

Le développeur affecté examine le problème. Les développeurs peuvent effectuer une ou plusieurs des tâches suivantes pendant leur investigation :

  • Posez des questions plus précises dans les commentaires.
  • Documentez les résultats de l’analyse du code.
  • Proposer des solutions potentielles.
  • Demandez des informations supplémentaires.
  • Identifiez les zones de code associées affectées.

Cette phase de discussion garantit que tout le monde comprend le problème avant d’implémenter un correctif.

Étape 4 : Implémentation

Le développeur crée une branche de fonctionnalité et implémente le correctif. Le processus d’implémentation implique généralement les tâches suivantes :

  • Écriture ou modification de code.
  • Ajout ou mise à jour de tests.
  • Vérification du correctif localement.
  • Préparation d'une pull request (PR).

Étape 5 : Lier les validations et les pull requests

GitHub connecte automatiquement des problèmes aux modifications de code lorsque vous les référencez dans des messages de validation ou des descriptions de demande de tirage (pull request) en utilisant des mots clés :

  • Fixes #123
  • Closes #123
  • Resolves #123

Exemple de message de validation :

Fix SQL injection vulnerability in search function

Implement parameterized queries to prevent SQL injection attacks.
Add input validation for search parameters.

Fixes #42

L’utilisation de mots clés pour référencer des problèmes crée une traçabilité entre le problème et sa solution. Lorsque la demande de tirage (pull request) est fusionnée, GitHub ferme automatiquement le problème référencé. Cette automatisation garantit que les problèmes ne restent pas ouverts une fois qu’ils sont résolus et créent un lien permanent entre la description du problème et les modifications de code qui l’ont résolue.

Étape 6 : Fermeture et vérification

Lorsque la demande de tirage (pull request) est fusionnée, le problème se ferme automatiquement (s’il est correctement référencé). Si le test révèle que le problème n’est pas entièrement résolu, il peut être rouvert pour plus de travail.

Bonne pratique : après la fermeture, vérifiez que les critères d’acceptation dans la description du problème d’origine sont satisfaits. Pour les problèmes de sécurité, envisagez une vérification supplémentaire par le biais de tests de sécurité.

Gérer les problèmes GitHub dans Visual Studio Code

Visual Studio Code s’intègre directement aux problèmes GitHub via l’extension GitHub Pull Requests. Cette intégration vous permet de :

  • Affichez les problèmes attribués sans quitter l’éditeur.
  • Créez de nouveaux problèmes à partir de Visual Studio Code.
  • Lier des modifications de code aux problèmes au fur et à mesure que vous travaillez.
  • Passez en revue les détails du problème en même temps que votre code.

Pour accéder aux problèmes GitHub dans Visual Studio Code :

  1. Installer l’extension « Demandes de tirage GitHub et problèmes ».
  2. Connectez-vous à votre compte GitHub.
  3. Affichez les problèmes dans le panneau GitHub.
  4. Filtrez par assignee, étiquettes ou jalons.

Cette intégration étroite simplifie votre flux de travail en gardant le contexte de problème visible pendant que vous codez.

Pourquoi la gestion efficace des problèmes importe

Un suivi des problèmes efficace empêche les problèmes critiques de passer inaperçus, en particulier en matière de sécurité. Tenez compte de ces scénarios réels :

  • Les problèmes mineurs deviennent des incidents majeurs : un problème de sécurité « mineur » dans le backlog peut devenir un incident grave si les attaquants le découvrent en premier. Les problèmes de sécurité dans GitHub Issues sont visibles et traçables : utilisez cette visibilité en tant qu’outil de responsabilité.

  • Connaissance institutionnelle perdue : lorsque les problèmes sont mal documentés ou que des discussions se produisent en dehors du système de suivi, un contexte précieux disparaît. Les futurs développeurs (y compris vous en six mois) peuvent ne pas comprendre pourquoi certaines décisions ont été prises.

  • Réponses différées : sans étiquettes de priorité claires et affectations, les vulnérabilités de sécurité critiques peuvent ne pas recevoir d’attention en temps opportun.

Adopter le développement piloté par les problèmes : identifiez le problème, corrigez-le, vérifiez le correctif, fermez le problème et passez à l’action. Cette approche systématique garantit l’exhaustivité et renforce la confiance dans votre codebase.

Résumé

GitHub Issues fournit la base de la résolution systématique des problèmes dans le développement de logiciels. Comprendre comment lire, interpréter et gérer efficacement les problèmes est essentiel avant de pouvoir les résoudre efficacement.