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 capacités via un self‑service gouverné.
Ces capacités sont livrées sous forme de modules versionnés (golden paths) : une interface de configuration claire, des templates (IaC/CI), des garde‑fous, de la doc, et des baselines opérationnelles.
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 (microservice sécurisé, data pipeline, environnements éphémères, etc.).
En cas de doute, privilégiez le chemin recommandé par l’équipe plateforme : c’est celui qui est supporté, observé et conforme by design.
2) Le configurer (piloté par schéma)
Les modules exposent un schéma de configuration typé. L’objectif :
- rendre les prérequis explicites,
- réduire le savoir tribal,
- éviter les configurations “snowflakes”.
En pratique, vous fournissez des paramètres (runtime, région, taille, SLO, etc.) et Argy orchestre les workflows sous-jacents.
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,
- conserver des policies homogènes.
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) Observer et opérer (run automation)
Argy encourage un delivery “run‑aware” :
- baselines d’observabilité (dashboards/alerting),
- runbooks embarqués,
- signaux d’ownership,
- preuves de gouvernance (qui a changé quoi, quand).
Voir : Run & Opérations.
Quand vous avez besoin d’évolutions
Si le golden path manque d’un élément, évitez de le forker par équipe. Préférez :
- remonter le besoin à l’équipe plateforme,
- ajouter un point d’extension,
- publier une nouvelle version.
Ainsi, les améliorations sont mutualisées et l’adoption ne se fragmente pas.
Aller plus loin
- Comprendre l’évolution des chemins : Versionnage & cycle de vie
- Parcourir des scénarios réels : Cas d’usage
- Explorer des exemples : Actions automatisables