Seulement les lignes que vous avez modifiées
La dette ancienne du même fichier reste mesurée par ArchScan, mais ne devient jamais du bruit de revue sur votre merge request.
- Nouvelle violation : commentée
- Dette existante : pas de commentaire
Un architecte senior sur chaque pull request.
ArchPilot intervient dès l'ouverture d'une pull/merge request, lit le code modifié selon vos règles d'architecture et laisse le correctif en commentaire de revue en ligne.
Écrans d'une installation en fonctionnement
Le parcours d'une merge request
Six étapes entre votre CI et le panneau AppArch, tous deux dans votre réseau. Le dépôt n'est jamais envoyé ; seuls les constats circulent.
- CI et Git
Une merge request s'ouvre
Une nouvelle MR, ou un nouveau push dessus, lance votre pipeline.
- CI et Git
Le job d'analyse démarre
Il récupère le jeu de règles depuis le panneau, avec les réglages du projet et de l'espace déjà appliqués.
- CI et Git
Seuls les fichiers modifiés sont lus
En mode revue, l'analyseur identifie d'abord les fichiers modifiés et ne lit qu'eux.
- Panneau AppArch
Les constats partent vers le panneau
Règle, fichier, ligne et message partent vers le panneau ; le dépôt lui-même n'est jamais envoyé.
- Panneau AppArch
Nouveau, répété ou corrigé
Le panneau compare avec l'exécution précédente : un nouveau constat est commenté, un constat répété n'est pas republié, un constat corrigé est résolu.
- CI et Git
Commentaires et résumé arrivent
Des commentaires en ligne sur les lignes exactes, et une section AppArch avec les totaux dans la description de la MR.
Seuil optionnel : choisissez une sévérité fail-on dans le panneau ; dès qu'un constat l'atteint, le job se termine avec le code 4, après l'envoi des résultats, et la pipeline passe au rouge.
Anatomie d'un commentaire
Chaque commentaire répond aux cinq mêmes questions et a le même aspect sur les quatre fournisseurs Git.
-
Règle et sévérité
Quelle règle, et quelle gravité. La sévérité pilote le score et le seuil optionnel.
-
La ligne exacte
Le commentaire se place sur la ligne fautive, jamais sur une annotation au-dessus.
-
Pourquoi c'est important
Le raisonnement, pour que la correction soit une décision et non une supposition.
-
Suggestion
Ce qu'il faut changer, tel que l'analyseur le suggère.
-
Détails de la règle
Un lien vers la page de documentation de la règle.
La vie d'un constat sur une merge request
Un commentaire par constat, du premier au dernier push. Un constat se ferme un par un : corrigé, ou fermé par une personne.
- TrouvéLe push qui l'introduit : un commentaire en ligne.
- Toujours làPushs suivants : le commentaire reste, aucun doublon.
- CorrigéLa ligne ne viole plus la règle : le commentaire est résolu.Fermé à la mainUne personne le ferme : il compte comme écarté, jamais comme corrigé.
Quatre fournisseurs Git, un seul comportement
Les commentaires sont publiés par l'utilisateur d'intégration par défaut ou par un compte bot dédié à l'espace de travail.
GitHub GitLab Bitbucket Azure DevOps
Ce qu'il y a sous le capot
ArchPilot n'est pas un linter - il se comporte comme un architecte qui s'intègre au flux de votre équipe sans le bruit.
Commentaires de revue en ligne
Le constat apparaît sur la ligne exacte - expliquant ce qui ne va pas, pourquoi, et la correction suggérée, tout comme un relecteur humain. Vous pouvez répondre dans le fil pour en discuter.
Analyse limitée au diff
Seul le code modifié dans cette PR/MR est analysé. La dette héritée ne devient jamais du bruit - l'équipe se concentre uniquement sur le risque qu'elle introduit maintenant.
Dédupliqué et résolu automatiquement
Les commentaires sont indexés par marqueur : le même constat n'est jamais republié à chaque push, et les violations corrigées se résolvent automatiquement. La PR reste propre et lisible.
Compte bot dédié + langue des commentaires
Les commentaires sont publiés par l'utilisateur d'intégration par défaut ou par un compte bot dédié à l'espace de travail. Vous choisissez la langue des commentaires par espace de travail (EN/TR).
Revues manuelles à la demande
Déclenchez une revue sur une MR spécifique directement depuis le panneau. ArchPilot vérifie d'abord l'accès ("puis-je le lire ?"), puis exécute la revue dans votre propre pipeline CI.
Synchronisation des développeurs et notation
Les membres Git et les auteurs de MR sont synchronisés automatiquement ; les comptes de service/bot sont marqués automatiquement (et modifiables). Chaque développeur obtient un score basé sur ArchPilot.
Surcharges de règles par projet
Activez, désactivez ou ajustez les règles par projet ou par espace de travail. Les règles que vous désactivez dans le panneau n'atteignent jamais le bot - aucun faux positif.
S'exécute dans votre propre CI
L'analyse s'exécute dans votre propre CI, sur votre propre infrastructure - votre code source ne la quitte jamais ; seuls les constats sont envoyés au panneau.
Voir dans le produit
Toutes les captures
Obtenez votre première revue dès aujourd'hui
Connectez Git, activez les règles et laissez ArchPilot s'exprimer sur la prochaine PR.