osFoundry / Platform
Pipeline de build et CI
Chaque push déclenche install → lint → build → deploy. Journaux streamés, artefacts conservés.
Présentation
Le pipeline de build et la CI forment la couche d'intégration continue derrière Apps & Backend d'osFoundry. Quand vous poussez le code d'une app, osFoundry exécute une séquence fixe et prévisible : installer les dépendances, linter, builder, puis déployer. Aucun service de CI séparé à brancher, aucun YAML à écrire à la main, aucun runner à provisionner. Le pipeline fait partie de l'espace de travail, donc livrer une app est le même geste que d'y enregistrer votre travail.
Au sein d'osFoundry, le pipeline est ce qui transforme un push en une app en production. Chaque étape s'exécute dans l'ordre et s'arrête au premier échec, de sorte qu'une erreur de lint ou un build cassé n'atteint jamais le déploiement. Les logs de chaque étape vous parviennent à mesure que l'exécution avance, ce qui veut dire que vous voyez la sortie d'installation, les avertissements du lint et les erreurs de build en temps réel, au lieu d'attendre une croix rouge puis de fouiller un dump après coup. Quand le build réussit, les artefacts produits sont conservés, si bien que chaque version déployée laisse une trace durable que vous pouvez rouvrir, et non un build qui s'évanouit dès qu'il se termine.
Cela compte parce que la partie lente d'une livraison est en général la boucle entre un déploiement raté et la compréhension de sa cause. Les logs en direct raccourcissent cette boucle : vous voyez l'étape et la ligne exactes où l'exécution a cassé, depuis l'espace de travail même où vous écrivez chat, agents, code et données. Comme osFoundry est bring-your-own-key et local-first, le pipeline s'inscrit dans un flux où vous gardez la maîtrise de vos clés et de vos données, plutôt que de confier votre processus de build à un fournisseur de CI tiers doté de sa propre tarification par siège et de son propre endroit où stocker vos logs.
Fonctionnalités clés
- Chaque push exécute les mêmes quatre étapes dans l'ordre : installer, linter, builder, déployer
- Le pipeline s'arrête à la première étape en échec, donc un build cassé n'est jamais déployé
- Les logs de chaque étape arrivent en direct pendant l'exécution, pas une fois qu'elle est finie
- Les artefacts sont conservés par version, laissant une trace durable de ce que vous avez livré
- Aucun service de CI séparé, runner ni YAML écrit à la main : c'est intégré à l'espace de travail
Cas d’usage
- Développeur solo : poussez une app et suivez installation, lint et build en direct, en attrapant une étape de lint en échec avant tout déploiement
- Petite équipe livrant des apps internes : appuyez-vous sur la séquence fixe installer-linter-builder-déployer pour qu'aucun build non relu ou cassé n'atteigne les utilisateurs
- Développeur en train de déboguer un déploiement : parcourez les artefacts conservés et les logs en direct d'une exécution passée pour trouver l'étape exacte où une version a cassé
Questions fréquentes
Que se passe-t-il quand je pousse du code vers une app osFoundry ?
Un pipeline fixe : installer les dépendances, linter, builder, puis déployer. Les étapes s'exécutent dans l'ordre et le pipeline s'arrête à la première qui échoue, si bien qu'un lint ou un build en échec n'atteint jamais l'étape de déploiement.
Puis-je voir les logs de build pendant l'exécution ?
Oui. Les logs de chaque étape vous parviennent en direct à mesure que l'exécution avance, vous voyez donc la sortie d'installation, de lint et de build en temps réel, au lieu d'attendre la fin de l'exécution puis de lire un dump statique.
Les anciens builds sont-ils conservés après le déploiement ?
Oui. Les artefacts des builds réussis sont conservés, de sorte que chaque version déployée laisse une trace durable vers laquelle revenir, plutôt qu'un build qui disparaît une fois terminé.