Aller au contenu
Argy
Commencer gratuitement

Consommer des modules

Comment les développeurs utilisent les modules Argy (golden paths) via le portail/CLI pour provisionner, déployer et opérer avec garde-fous.

Avec Argy, les développeurs ne « demandent pas à la plateforme de faire ». Ils consomment des modules (golden paths) via un self‑service gouverné.

Les modules sont des workflows versionnés avec schémas et exécution gouvernée.

Ce que vous faites typiquement en tant que développeur

1) Choisir un golden path (module)

Partez du catalogue de modules et choisissez un chemin adapté à votre charge.

Utilisez les statuts (stable / experimental / deprecated / draft) pour choisir ce qui est sûr à adopter.

2) Le configurer (piloté par schéma)

Les déploiements se configurent via un schéma typé (JSON Schema). L’objectif :

  • rendre les prérequis explicites,
  • réduire le savoir tribal,
  • éviter les configurations “snowflakes”.

En pratique, vous remplissez un formulaire généré depuis le schéma.

3) Appliquer par environnement

La plupart des produits ont plusieurs environnements (DEV/STG/PRD). Avec Argy, vous pouvez :

  • réutiliser le même golden path,
  • ne modifier que les paramètres qui diffèrent,
  • appliquer une gouvernance par environnement (par exemple : approbation requise en production).

4) Livrer via portail/CLI

Utilisez le portail pour la visibilité et des parcours guidés. Utilisez le CLI pour automatiser (CI/CD, scripts) ou si le terminal est votre UX par défaut.

L’idée clé : l’équipe plateforme contrôle le chemin, les développeurs contrôlent les paramètres.

5) Suivre l’exécution (pipelines)

Chaque déploiement produit des runs suivis de bout en bout :

  • statuts (QUEUED, WAITING_APPROVAL, RUNNING, SUCCEEDED, FAILED, CANCELED),
  • logs temps réel (WebSocket),
  • outputs (JSON structuré),
  • artefacts et exports.

Vous pouvez annuler, relancer, approuver/rejeter (si applicable), et exporter logs et artefacts.

Quand vous avez besoin d’évolutions

Si le golden path manque d’un élément, évitez de le forker par équipe. Préférez :

  1. remonter le besoin à l’équipe plateforme,
  2. ajouter un point d’extension,
  3. publier une nouvelle version.

Ainsi, les améliorations sont mutualisées et l’adoption ne se fragmente pas.

Aller plus loin