Compatibilité CI/CD : un impératif pour les outils d'agent

Ceci est une série en 10 parties expliquant comment Apidog a développé Apidog CLI, un outil en ligne de commande pour les tests et la gestion du cycle de vie des API. Lisez dans l'ordre ou accédez directement à n'importe quel article qui vous intéresse :

La convivialité pour les agents doit être construite sur la convivialité pour le CI/CD. Découvrez pourquoi apidog run sert à la fois les pipelines CI et les agents IA — et pourquoi cette double finalité est importante.

Le public double

Lors de la création d'outils d'agent, il est facile de se concentrer uniquement sur l'expérience conversationnelle.

Apidog CLI a une cible de service importante qui ne doit pas être oubliée : le CI/CD.

De nombreuses équipes utilisent déjà Apidog dans leurs pipelines pour :

• Exécuter des tests API automatisés
• Générer des rapports
• Maintenir des seuils de qualité

Ce scénario nécessite :

L'automatisation ne peut pas être rompue juste pour accommoder les agents.

Le principe principal

La convivialité pour les agents doit être construite sur la convivialité pour le CI/CD.

Nous n'avons pas réinventé un protocole qui ne peut être utilisé que par l'IA. Nous avons ajouté une sortie structurée, une validation de schéma et des conseils pour les étapes suivantes dont les agents ont besoin en plus d'un formulaire déjà validé par les systèmes d'ingénierie.

Les bons outils d'ingénierie CLI à l'ère des agents devraient être capables de servir :

apidog run : La commande principale

La base reste :

apidog run --project <projectId> \
  --test-scenario <scenarioId> \
  --environment <environmentId> \
  -r "cli,html,junit" \
  --out-dir ./apidog-reports

Cette commande sert les quatre consommateurs.

Ce qui intéresse le CI

Exemple d'utilisation CI :

# GitHub Actions
- name: Exécuter les tests API
  run: |
    apidog run --project $PROJECT_ID \
      --test-scenario $SCENARIO_ID \
      --environment $ENV_ID \
      -r "junit" \
      --out-dir ./reports
  env:
    PROJECT_ID: ${{ secrets.APIDOG_PROJECT_ID }}
    SCENARIO_ID: ${{ secrets.APIDOG_SCENARIO_ID }}
    ENV_ID: production

- name: Publier le rapport de test
  uses: mikepenz/action-junit-report@v3
  with:
    report_paths: './reports/junit.xml'

Le pipeline lit le code de sortie → réussit ou échoue → publie le rapport.

Ce qui intéresse les agents

Exemple d'utilisation d'agent :

{
  "success": true,
  "stats": {
    "total": 10,
    "passed": 8,
    "failed": 2
  },
  "failures": [
    {
      "step": "Traitement des paiements",
      "error": "Assertion failed: status != 'success'",
      "response": {...}
    }
  ],
  "agentHints": {
    "summary": "2 tests ont échoué. Examiner les détails des échecs.",
    "nextSteps": [
      "Déboguer l'échec de l'étape de traitement des paiements.",
      "Vérifier l'assertion : statut attendu 'success'.",
      "Mettre à jour le cas de test ou le point d'accès après la correction."
    ]
  }
}

L'agent analyse le JSON → comprend les échecs → suit les étapes suivantes.

Même commande, différents consommateurs

apidog run --project <projectId> --out-dir ./apidog-reports

Une seule commande sert tout le monde.

Points d'intégration

Apidog CLI prend en charge l'intégration avec :

Toutes les intégrations utilisent la même base apidog run.

Porte de qualité vs Vérification

Même commande, contexte différent :

Le principe fondamental

Tout ce que nous avons décrit dans cette série — cli-schema, agentHints, SKILL — repose sur cette fondation :

┌─────────────────────────────────────────┐
│          Fonctionnalités Agent           │
│  (cli-schema, agentHints, SKILL)        │
├─────────────────────────────────────────┤
│          Fondation CI/CD                │
│  (apidog run, codes de sortie, rapports)│
├─────────────────────────────────────────┤
│          CLI principale                 │
│  (commandes, paramètres, exécution)     │
└─────────────────────────────────────────┘

Les fonctionnalités des agents ne remplacent pas les fonctionnalités CI. Elles les étendent.

Et ensuite ?

Nous avons couvert l'ensemble du tableau – de la découverte du problème aux flux de travail pratiques et aux principes fondamentaux.

Il reste maintenant un élément crucial : la sécurité.

Lorsque les agents modifient les ressources du projet, comment les empêcher d'affecter directement la branche principale ?

Dans la partie 9, Branche IA : Des changements de projet plus sûrs avec les agents IA, nous explorerons comment la branche IA fournit un environnement d'édition isolé – les changements restent dans une branche distincte jusqu'à la révision humaine, créant une couche de sécurité pour les modifications pilotées par les agents.

Points clés à retenir

• La compatibilité CI/CD est la fondation, pas une option
• La convivialité pour les agents est construite sur la convivialité CI
• Une même commande (apidog run) sert le CI, les agents, les humains, les scripts
• Besoins du CI : codes de sortie, rapports, paramètres stables
• Besoins des agents : sortie structurée, détails des échecs, étapes suivantes
• Porte de qualité (CI) + vérification (Agent) = double objectif

Téléchargez Apidog pour concevoir, simuler, tester et documenter les API dans un seul espace de travail. En savoir plus sur Apidog CLI pour les tests API en ligne de commande, l'automatisation CI et les flux de travail des agents IA.