Depuis quelques années, l'architecture micro-services est de plus en plus présente dans l'écosystème moderne du développement logiciel pour la construction d'application scalable et maintenable. Cependant, cette approche apporte son lot de défis, notamment en matière de gestion des Pull Requests (PR) réparties sur plusieurs repositories.
Imaginez une équipe gérant 15 micro-services répartis dans autant de repositories GitHub. Chaque développeur doit jongler entre différents onglets, perdre du temps à naviguer d'un repo à l'autre pour suivre l'état des reviews, et les tech leads peinent à avoir une vision globale de l'activité de développement. Cette fragmentation nuit à la productivité et peut impacter la qualité du code par manque de visibilité.
GitHub Project View offre une solution à cette problématique en permettant de centraliser la gestion des PR dans une interface unique et personnalisable. Couplé à l'automatisation via GitHub Actions, il devient possible de créer un tableau de bord intelligent qui agrège automatiquement toutes les Pull Requests de vos micro-services.
Dans cet article, nous explorerons comment mettre en place cette solution de centralisation, depuis la configuration des workflows d'auto-enregistrement jusqu'à l'optimisation de votre Project View pour maximiser l'efficacité de votre équipe.
Les défis de la gestion multi-repositories
L'architecture micro-services, bien qu'apportant de nombreux avantages en termes de scalabilité et d'indépendance des équipes, introduit une complexité organisationnelle significative. Chaque service dispose généralement de son propre repository, créant un écosystème distribué où l'information se trouve éparpillée.
Problématiques courantes rencontrées :
- Perte de visibilité globale : Les tech leads doivent consulter manuellement chaque repository pour connaître l'état des développements en cours
- Ralentissement des reviews : Les développeurs peuvent oublier des PR en attente dans des repositories qu'ils consultent moins fréquemment
- Coordination inter-équipes difficile : Lorsque plusieurs micro-services sont impactés par une même feature, synchroniser les releases devient complexe
- Reporting et métriques fragmentés : Impossible d'avoir des métriques consolidées sur les temps de review, le throughput des équipes, etc.
Impact sur la productivité
Ces problématiques se traduisent concrètement par :
- Augmentation du lead time : Le temps entre l'ouverture d'une PR et son merge s'allonge
- Augmentation du context switching : Les développeurs perdent du temps à naviguer entre les interfaces et les différents repositories
- Risques de régression : Des PR importantes peuvent passer inaperçues et ne pas recevoir l'attention nécessaire
Vers une solution centralisée
L'objectif est de recréer l'expérience fluide d'un monorepo tout en conservant les avantages de l'architecture distribuée. GitHub Project View, lancé en 2022, offre les primitives nécessaires pour construire cette vue unifiée, à condition de l'alimenter intelligemment via l'automatisation.
Présentation de GitHub Project View
Fonctionnalités clés
GitHub Project View représente une évolution majeure des anciens GitHub Projects. Il s'agit d'un outil de gestion de projet natif qui s'intègre avec l'écosystème GitHub et offre des capacités avancées de visualisation et d'organisation.
Quelques caractéristiques principales :
- Vues multiples : Table, Board (Kanban), Timeline, et vues personnalisées
- Champs personnalisés : Possibilité d'ajouter des métadonnées spécifiques (priorité, estimation, équipe responsable, etc.)
- Filtrage avancé : Requêtes complexes pour segmenter l'information
- Automatisation native : Workflows intégrés pour automatiser les transitions d'état
- API GraphQL : Intégration programmatique pour l'alimentation automatique
Avantages pour la gestion multi-repos
Contrairement aux solutions externes (Jira, Trello, etc.), GitHub Project View bénéficie d'une intégration native avec les Pull Requests, Issues, et autres objets GitHub. Cette intégration permet :
- Synchronisation temps réel : Les changements d'état des PR se reflètent immédiatement
- Contexte préservé : Accès direct aux détails techniques (diff, CI/CD status, reviews)
- Workflow unifié : Pas de rupture dans l'expérience développeur
Architecture de la solution
Vue d'ensemble de l'approche
L'architecture que nous proposons repose sur un principe simple : l'automatisation événementielle. Chaque action significative sur une Pull Request (création, mise à jour, merge, etc.) déclenche un workflow GitHub Actions qui se charge de synchroniser l'information avec le Project View centralisé. L'exemple proposé permet de simplement ajouter une nouvelle PR au projet lorsqu'elle est ouverte. La bascule à DONE lorsqu'elle est fusionnée est automatique grace aux workflows.
Composants techniques impliqués
1. GitHub Actions Workflows
- Déclenchés par les événements
pull_requestetpull_request_review - Responsables de l'extraction des métadonnées et de l'appel API
- Gestion des erreurs et retry logic
2. GitHub GraphQL API
- Point d'entrée pour manipuler les Project Views
- Mutations pour ajouter/modifier les items du projet
- Queries pour récupérer les IDs et structures nécessaires
3. Project View centralisé
- Repository dédié ou attaché à l'organisation
- Configuration des champs personnalisés
- Définition des vues et filtres
Flux de données et interactions
Le processus de synchronisation suit ce workflow :
- Déclenchement : Une PR est créée/modifiée dans un micro-service
- Extraction : Le workflow récupère les métadonnées (auteur, labels, statut CI/CD)
- Enrichissement : Ajout d'informations contextuelles (nom du service, équipe)
- Synchronisation : Mise à jour du Project View via l'API GraphQL
- Notification : Optionnellement, notification Slack/Teams de l'équipe
Configuration du GitHub Project View
Création et paramétrage de la vue projet
La création du Project View centralisé constitue le cœur de notre solution. Voici les étapes détaillées pour configurer un projet optimisé pour la gestion des Pull Requests multi-repositories.
Étape 1 : Création du projet
- Naviguez vers votre organisation GitHub
- Cliquez sur l'onglet "Projects" puis "New project"
- Sélectionnez "Table" comme vue par défaut
- Nommez votre projet (ex: "Central PR Dashboard - My Project")
Étape 2 : Configuration du projet
- Allez dans les paramètres du projet ("..." en haut à droite puis "Settings")
- Créer les status correspondants à votre workflow (par exemple : "To review", "Review in progress", "Rework", "Approved" et "Done"). Les statuts peuvent être réordonnées via le bouton "..." situé sur la ligne du statut
- Ajoutez les champs personnalisés si nécessaire (lien Jira si vous suivez une nomenclature de nommage de PR, nom du service, statut de la CI, etc.)
- Par défaut des workflows "projet" sont activés, si vous ne souhaitez pas les avoir désactivez-les dans la vue projet en cliquant sur "Workflows". Voici une liste de workflow, permettant de gérer les items de votre vue projet, que vous pouvez activer (et modifier si besoin) :
- "Auto-archive items" : en modifiant le filtre vous pouvez automatiquement archiver les items PR qui sont au statut fermées ou fusionnées. Par défaut, la vue affiche les items au statut "Done". Grâce à ce workflow, archivez automatiquement les items après un certain temps
- "Code changes requested" : bascule le statut d'un item PR lorsqu'une revue a été effectuée entrainant un rework sur celle-ci
- "Code review approved" : bascule le statut d'un item PR lorsqu'une revue a été effectuée avec une approbation
- "Item closed" : bascule le statut d'un item PR à "Done" lorsqu'elle est fermée (clôture sans fusion)
- "Pull request merged" : bascule le statut d'un item PR à "Done" lorsqu'elle est fusionnée
Étape 3 : Configuration de la vue
- Ajoutez un filtre si besoin pour la vue principale (pour retirer les PR de dependabot par exemple, n'avoir que les PR ouvertes via
is:open) - Ajoutez ou retirez les champs pour avoir un dashboard avec des éléments utiles uniquement
- Groupez les PR par service ou par feature (possible de faire une vue pour chaque !)
Mise en place de l'auto-enregistrement via workflows
Configuration des GitHub Actions
Chaque repository de micro-service doit inclure un workflow dédié à la synchronisation. Pour plus de simplicité, n'hésitez pas à centraliser ces workflows dans un projet dédié pour les réutiliser plus simplement. Voici un exemple simple de configuration :
name: Sync PR to Central Project
on:
pull_request:
types: [opened, reopened, ready_for_review]
jobs:
pr-project:
if: ${{ !github.event.pull_request.draft }}
runs-on: ubuntu-latest
steps:
- name: Get project data
env:
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
ORGANIZATION: YOUR_ORGANIZATION
# Created at the previous step
PROJECT_NUMBER: YOUR_PROJECT_ID
run: |
gh api graphql -f query='
query($org: String!, $number: Int!) {
organization(login: $org){
projectV2(number: $number) {
id
fields(first:20) {
nodes {
... on ProjectV2Field {
id
name
}
... on ProjectV2SingleSelectField {
id
name
options {
id
name
}
}
}
}
}
}
}' -f org=$ORGANIZATION -F number=$PROJECT_NUMBER > project_data.json
echo 'PROJECT_ID='$(jq '.data.organization.projectV2.id' project_data.json) >> $GITHUB_ENV
echo 'DATE_FIELD_ID='$(jq '.data.organization.projectV2.fields.nodes[] | select(.name== "Date posted") | .id' project_data.json) >> $GITHUB_ENV
echo 'TODO_OPTION_ID='$(jq '.data.organization.projectV2.fields.nodes[] | select(.name== "Status") | .options[] | select(.name=="Todo") |.id' project_data.json) >> $GITHUB_ENV
echo 'STATUS_FIELD_ID='$(jq '.data.organization.projectV2.fields.nodes[] | select(.name== "Status") | .id' project_data.json) >> $GITHUB_ENV
echo 'JIRA_FIELD_ID='$(jq '.data.organization.projectV2.fields.nodes[] | select(.name== "Jira") | .id' project_data.json) >> $GITHUB_ENVDans cette étape nous appelons l'API GraphQL de GitHub pour récupérer les informations du projet. Nous récupérons notamment l'identifiant du projet ainsi que les identifiants des champs "Date posted", "Status" (et la valeur de l'option Todo) et "Jira".
- name: Add PR to project
env:
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
PR_ID: ${{ github.event.pull_request.node_id }}
run: |
item_id="$( gh api graphql -f query='
mutation($project:ID!, $pr:ID!) {
addProjectV2ItemById(input: {projectId: $project, contentId: $pr}) {
item {
id
}
}
}' -f project=$PROJECT_ID -f pr=$PR_ID --jq '.data.addProjectV2ItemById.item.id')"
echo 'ITEM_ID='$item_id >> $GITHUB_ENVDans cette étape nous rajoutons la PR au projet.
- name: Get date
run: echo "DATE=$(date +"%Y-%m-%d")" >> $GITHUB_ENV
- name: Get Jira
run: |
JIRA_LINK=""
if [[ "${{ github.event.pull_request.title }}" =~ ^.*XXX-[0-9]+.*$ ]]; then
JIRA_REF=$(echo "${{github.event.pull_request.title}}" | sed -nE 's/.*\[(XXX-[0-9]+)\].*/\1/p')
JIRA_LINK="https://myorg.atlassian.net/browse/${JIRA_REF}"
fi
echo 'JIRA_LINK='$JIRA_LINK >> $GITHUB_ENVDans ces étapes nous récupérons les valeurs pour les champs "Date" et "Jira". Pour ce dernier, nous extrayons l'information à partir du titre de la PR. Pour que ceci fonctionne il est nécessaire de forcer une nomenclature sur les noms des PR avec la référence Jira entre crochet, sans quoi cela ne fonctionnera pas.
- name: Set fields
env:
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
run: |
gh api graphql -f query='
mutation (
$project: ID!
$item: ID!
$status_field: ID!
$status_value: String!
$date_field: ID!
$date_value: Date!
$jira_field: ID!
$jira_value: String!
) {
set_status: updateProjectV2ItemFieldValue(input: {
projectId: $project
itemId: $item
fieldId: $status_field
value: {
singleSelectOptionId: $status_value
}
}) {
projectV2Item {
id
}
}
set_date_posted: updateProjectV2ItemFieldValue(input: {
projectId: $project
itemId: $item
fieldId: $date_field
value: {
date: $date_value
}
}) {
projectV2Item {
id
}
}
set_jira: updateProjectV2ItemFieldValue(input: {
projectId: $project
itemId: $item
fieldId: $jira_field
value: {
text: $jira_value
}
}) {
projectV2Item {
id
}
}
}' -f project=$PROJECT_ID -f item=$ITEM_ID -f status_field=$STATUS_FIELD_ID -f status_value=${{ env.TODO_OPTION_ID }} -f date_field=$DATE_FIELD_ID -f date_value=$DATE -f jira_field=$JIRA_FIELD_ID -f jira_value=$JIRA_LINK --silentDans cette dernière étape nous appelons l'API GraphQL de GitHub pour modifier les informations de notre PR dans la vue projet : nous modifions l'état de ses attributs avec les informations collectées.
Cette première version vous permettra dans un premier temps de centraliser vos PR à leur ouverture, tout en se nettoyant à la fusion de celle-ci.
Pour plus d'automatisation, la documentation GitHub est complète, vous trouverez certainement quelque chose d'intéressant ici (notamment pour affiner les status liés au cycle de relecture).
Bonnes pratiques et recommandations
Conseils de mise en œuvre
- Commencez par 2-3 repositories pilotes
- Validez le workflow avant de généraliser
- Formez les équipes aux nouveaux processus
Pièges à éviter
- Sur-automatisation : Ne pas automatiser au détriment de la flexibilité
- Champs trop nombreux : Limiter les métadonnées aux informations réellement utiles
- Permissions insuffisantes : S'assurer que le token a les droits nécessaires sur tous les repositories
Évolutions possibles
- Ajouter des workflows pour les revues avec bascule de statut ("To review", "Review in progress", "To rework", etc.)
- Ajouter un système d'alerte pour les PR "oubliées" (sans mise à jour depuis X jours)
Cette solution s'inscrit dans une démarche plus large d'amélioration continue des pratiques DevOps, où l'automatisation intelligente permet aux équipes de se concentrer sur la valeur métier plutôt que sur les tâches organisationnelles. L'écosystème GitHub continue d'évoluer rapidement et cette approche constitue une base solide pour intégrer les futures innovations en matière de gestion de projet et d'automatisation.
