railyard.yml : la configuration de votre application comme un seul fichier dans git

La configuration en tant que code est habituellement vendue comme une promesse plus grande que ce qu’elle fait mécaniquement le premier jour. Ça vaut la peine d’être précis ici, parce que survendre cette fonctionnalité précise serait exactement le genre de chose que ce blogue essaie d’éviter : railyard.yml aujourd’hui, ce sont trois commandes simples, pas un pipeline complet de plan/apply/drift — et savoir exactement où se situe cette limite est plus utile qu’une description plus vague et plus grandiose.

Les trois commandes

railyard manifest:pull my-app --out railyard.yml
railyard manifest:apply my-app railyard.yml
railyard manifest:validate railyard.yml

• manifest:pull affiche la configuration actuelle d’une application comme fichier railyard.yml — ajoutez --secrets et ça inclut les valeurs des variables, pas juste les noms. C’est comme ça qu’on obtient un point de départ : récupérer ce qui tourne déjà, plutôt qu’écrire le fichier depuis une page blanche.
• manifest:apply applique un fichier à une application directement.
• manifest:validate vérifie un fichier local — ./railyard.yml si vous n’en nommez pas — contre le schéma sans aucune application impliquée et rien d’appliqué. Les clés inconnues reçoivent une vraie suggestion (contaner_port → « vouliez-vous dire container_port? »), pas juste une erreur de parsing générique. Ça sort avec le code 0 et affiche « is valid » quand rien ne cloche, ou le code 1 et liste chaque problème trouvé.

À quoi sert vraiment cette combinaison

Lancer validate en CI avant un déploiement attrape une clé mal tapée ou une valeur malformée avant qu’elle n’atteigne une vraie application — une assurance bon marché qui coûte une commande dans un pipeline. pull puis apply est la façon dont la configuration se déplace entre les environnements sans re-cliquer à travers un tableau de bord pour chacun : récupérez la configuration du staging, ajustez ce qui est vraiment différent, appliquez-la à la production.

L’API REST soutient la même chose directement — GET /api/applications/:id/manifest renvoie le même fichier (?secrets=true pour les valeurs), pour tout ce qui veut scripter autour de ça au-delà de la CLI.

Ce que ce n’est pas, pour l’instant

Il n’y a pas d’étape plan qui montre une différence avant d’appliquer — apply applique, c’est tout. Il n’y a pas de détection de dérive qui vous dit que la production a tranquillement divergé du fichier dans git. Si ça compte pour la façon dont votre équipe travaille aujourd’hui, traitez railyard.yml comme un instantané de configuration et un mécanisme de transport, pas comme une garantie que git et la réalité restent synchronisés sans que vous vérifiiez.

Le dire clairement ici, c’est le point : une fonctionnalité de configuration en tant que code n’est vraiment utile qu’une fois qu’on sait précisément ce qu’elle vérifie pour vous et ce qu’elle vous laisse encore remarquer vous-même.

Référence complète des commandes : CLI.