Les cinq phases en pratique

Suivez une fonctionnalité à travers la Préparation, la Vérification, le Plan, le Développement et la Documentation, et découvrez ce que permet chaque page.

Ce que vous allez apprendre

Ce que vous pouvez modifier sur la page Préparation après la première préparation.
Comment la Vérification et le Plan vous évitent de développer la mauvaise chose.
Comment le développement avance d’étape en étape.
Que faire quand une étape échoue.

Préparation : où se trouve le code

Pendant la préparation, Claude lit les tickets et trouve où chacun se situe : les commits qui le mentionnent, les noms qu’il contient et l’endroit où ce code est défini. Il utilise la recherche de code de votre organisation (Sourcebot), ou cherche directement dans GitLab s’il n’y en a pas. Il ne modifie rien.

La page Préparation affiche ensuite Les tickets et où ils sont développés, les branches par environnement et la façon dont la fonctionnalité est développée. Pour changer quoi que ce soit, utilisez Demander à Claude de modifier quelque chose : Claude vérifie les branches et les couches, puis propose la modification. Vous l’enregistrez comme nouvelle version de la configuration.

Vérification : les contrôles de l’application

L’application vérifie elle-même la configuration : les règles du validateur et les branches sur GitLab. Les problèmes sont listés avec ce qu’il faut corriger. Dites-le à Claude dans le panneau et il propose la correction. Demander à Claude de tout vérifier ajoute les vérifications qui demandent du jugement. Quand tout est juste, cliquez sur Continuer vers la planification.

Plan : le contrat

Établir le plan décrit, par dépôt et par ticket, ce qui va changer, en étapes appelées niveaux, avec les branches et le temps saisi sur chaque commit. En cas de désaccord, dites-le à Claude et Replanifiez. Aucune branche n’est créée avant Approuver et démarrer le niveau 1.

Développement : étape par étape

Claude développe les tickets une étape à la fois, dans une copie temporaire des dépôts, et ouvre une merge request par dépôt. Chaque push et chaque création de merge request attend votre approbation.

La page Développement affiche :

les Niveaux et leur avancement ;
les Merge requests, avec leurs remarques de revue ;
l’État d’exécution ;
les Maquettes liées aux tickets.

Quand une étape est terminée, cliquez sur Confirmer et passer à l’étape suivante. Certaines étapes exigent que la précédente soit fusionnée d’abord — par exemple, une API qui utilise une bibliothèque partagée a besoin que la merge request de la bibliothèque soit fusionnée et publiée. La page l’indique avant que vous confirmiez.

Exemple : team-invites a trois niveaux. Le niveau 1 modifie core-lib ; vous approuvez le push, un relecteur fusionne la merge request, et la bibliothèque est publiée. Ce n’est qu’ensuite que vous confirmez le niveau 2, où Claude adapte l’API des comptes à la nouvelle version de la bibliothèque.

Astuce : une seule étape tourne à la fois par fonctionnalité. Pendant que Claude travaille, un indicateur tourne à côté de la fonctionnalité dans Récents et dans le bouton Demander à Claude.

Documentation

Claude rédige la documentation d’exécution et les exports de collections d’API pour chaque environnement. Récupérez-les avec Télécharger sur la page Documentation, ou cliquez sur Réécrire la documentation après des modifications.

Quand une étape échoue

La page de la fonctionnalité indique pourquoi, et vous recevez une notification. La cause est souvent un jeton expiré ou une branche qui a bougé. Corrigez-la — par exemple en enregistrant un nouveau jeton GitLab dans Comptes connectés — puis relancez l’étape.

Astuce : modifier la configuration après le plan rend l’état d’exécution obsolète. La page vous demande de replanifier avant l’étape suivante, pour que le plan corresponde toujours à la configuration.

Vérifiez vos acquis

1. Où changer le dépôt dans lequel un ticket est développé, après la préparation ?

Sur la page Préparation, avec Demander à Claude de modifier quelque chose (ou en retirant le dépôt), puis en enregistrant la nouvelle version de la configuration.

2. Pourquoi la page peut-elle refuser que vous confirmiez déjà l’étape suivante ?

Le niveau suivant dépend d’un travail du niveau actuel qui doit d’abord être fusionné (et parfois publié).

3. Une étape de développement a échoué avec une erreur GitLab 401. Quelle est la correction probable ?

Votre jeton GitLab a expiré ou manque de droits. Enregistrez un nouveau jeton, puis relancez l’étape.