Vue d'ensemble des intégrations
AppArch accède à votre code via un identifiant (credential) pour votre plateforme Git. Tout le reste - CI, suivi des tickets, notifications, IA - est facultatif et se connecte séparément.
L’interface du produit existe en anglais et en turc ; les noms de menus sont donc donnés ici tels que l’interface anglaise les affiche.
Plateformes Git
Section intitulée « Plateformes Git »Les connexions Git s’ajoutent sous Credentials → Add credential. L’assistant comporte trois étapes : choisir le fournisseur, suivre la configuration propre au fournisseur, puis coller les valeurs.
| Plateforme | Authentification | Où elle peut être hébergée |
|---|---|---|
| GitHub | Jeton d’accès personnel (fine-grained ou classic) | github.com uniquement |
| GitLab | Application OAuth ou jeton d’accès personnel | gitlab.com ou un GitLab autogéré (par URL) |
| Bitbucket | Client OAuth ou jeton d’accès d’espace de travail / de dépôt | Bitbucket Cloud uniquement |
| Azure DevOps | Jeton d’accès personnel | Azure DevOps Services (dev.azure.com) uniquement |
Il n’existe pas de connexion générique « Git personnalisé ». Le seul serveur auto-hébergé qu’AppArch peut joindre est un GitLab autogéré - voir Git auto-hébergé.
Un jeton collé est vérifié auprès du fournisseur avant d’être enregistré : un jeton invalide, expiré ou sans accès en lecture est refusé. Les identifiants sont stockés chiffrés avec la clé maîtresse de l’installation.
L’opérateur de l’installation décide quels fournisseurs sont proposés (Administration → Settings → Policies, /management/settings/policies). Un fournisseur fermé disparaît de l’assistant et l’Api le refuse.
Systèmes de CI
Section intitulée « Systèmes de CI »Le runner (collector) est une image de conteneur qui s’exécute dans votre propre CI. Il reconnaît une pull/merge request grâce aux variables d’environnement propres à :
- GitHub Actions
- GitLab CI
- Bitbucket Pipelines
- Azure Pipelines
Toute autre CI lance la même image avec docker run et transmet explicitement le contexte de la PR - voir Jenkins. Configuration pour toutes : Ajouter le runner à la CI.
Autres intégrations
Section intitulée « Autres intégrations »Connectées par espace de travail sous Integrations :
- Jira, Trello - suivi des constats sous forme de tickets (Jira).
- SonarQube - correspondance des projets et mesures à côté de celles d’AppArch.
- Slack, Microsoft Teams - un Incoming Webhook ; aujourd’hui AppArch n’y envoie qu’un message de test de connexion (Slack).
- Kubernetes, Argo CD - état des déploiements pour le catalogue de services (détails).
- Dynatrace, New Relic, Percona - sources d’incidents et de performances.
- JMeter - résumés de tests de charge envoyés avec un jeton de projet.
L’opérateur peut fermer chacune d’elles pour toute l’installation sous Administration → Settings → Policies (/management/settings/policies).
L’IA n’est pas une intégration d’espace de travail : un fournisseur et une clé pour toute l’installation, définis par l’opérateur. Voir IA (Claude / OpenAI / Gemini).