Ingénierie
Comment un seul manifeste adios.yaml fait passer une application du local à la production
Un court fichier adios.yaml garde les décisions de compilation et d’exécution près du code, que la source provienne d’un dossier local ou d’un espace de travail partagé.
La configuration de déploiement est plus facile à comprendre lorsqu’elle se trouve à côté du code qu’elle décrit.
Garder un contrat simple
Un manifeste Adios définit le contrat d’exécution d’une charge de travail : comment la compiler et la démarrer, sur quel port elle écoute, et quelles variables d’environnement ou quels volumes elle attend. Ce sont les paramètres qui finissent généralement par diverger lorsqu’ils existent seulement dans un tableau de bord ou un guide d’exploitation maintenu à la main.
Définir ces paramètres dans adios.yaml rend le parcours de déploiement visible lors de la revue de code. Un collègue peut voir qu’une application Node.js se compile avec npm run build ou qu’un service Go produit un seul binaire, sans ouvrir d’abord la console de la plateforme.
- —La commande de compilation est reproductible à partir d’une copie propre du dépôt.
- —La commande de démarrage lance le processus de production, pas un serveur de développement.
- —Le port et l’adresse d’écoute fonctionnent dans un environnement d’exécution isolé.
- —Les identifiants requis utilisent des références à des secrets plutôt que des valeurs écrites en clair.
name: api
build_cmd: npm ci && npm run build
start_cmd: node dist/main.js
runtime:
name: node@24
port: 8080
health_path: /healthzUtiliser le même fichier quel que soit le parcours des sources
Les sources peuvent provenir d’un répertoire local, d’un dépôt Git ou d’un espace de travail Adios. Le manifeste transmet les mêmes instructions aux couches de compilation et d’exécution. Cette continuité compte lorsqu’un prototype rapide devient un service que l’équipe doit maintenir.
Vous pouvez modifier ensemble le code du framework et le contrat de déploiement, exécuter les vérifications utiles au projet et promouvoir le résultat sans le transposer dans un second système de configuration.
Préférer une configuration explicite aux astuces
Un manifeste doit être prévisible. Préférez une commande qu’un développeur peut exécuter et déboguer à une succession de conventions cachées. Utilisez des références pour les secrets, déclarez explicitement les données persistantes et faites en sorte que le contrôle de santé reflète ce que la charge de travail peut réellement servir.
Il y a ainsi moins de détails à retenir en cas de défaillance, et le parcours des sources à la production est plus facile à examiner.
Examiner les modifications du manifeste comme des changements opérationnels
Modifier start_cmd, un contrôle de santé ou un volume persistant peut affecter la disponibilité sans toucher au code de l’application. Examinez ces lignes avec autant de soin qu’une migration de base de données : que deviennent les réplicas existants, quelles données sont conservées et comment le nouveau processus démontrera-t-il qu’il est prêt ?
Une pull request utile explique le comportement d’exécution avant et après le changement, indique la commande utilisée pour vérifier la compilation et précise comment revenir en arrière. Le manifeste est court, mais reste du code de production.