osFoundry / Platform
Pipeline di build e CI
Ogni push avvia install → lint → build → deploy. Log in streaming, artefatti conservati.
Che cos’è
Build pipeline e CI sono il livello di continuous integration dietro Apps & Backend di osFoundry. Quando fai push del codice di un'app, osFoundry esegue una sequenza fissa e prevedibile: installa le dipendenze, esegue il lint, compila e poi fa il deploy. Non c'è un servizio di CI separato da collegare, nessuno YAML da scrivere a mano e nessun runner da predisporre. La pipeline fa parte del workspace, quindi pubblicare un'app è lo stesso gesto con cui vi salvi il tuo lavoro.
Dentro osFoundry è la pipeline a trasformare un push in un'app attiva. Ogni fase viene eseguita nell'ordine e si ferma al primo errore, così un errore di lint o una build rotta non arrivano mai al deploy. I log di ogni fase ti raggiungono man mano che l'esecuzione procede, il che significa che vedi l'output dell'installazione, gli avvisi del lint e gli errori di build in tempo reale, invece di aspettare una crocetta rossa e poi frugare in un dump a cose fatte. Quando la build va a buon fine, gli artefatti prodotti vengono conservati, così ogni versione che deployi lascia una traccia duratura a cui tornare, e non una build che svanisce nell'istante in cui finisce.
Questo conta perché la parte lenta della pubblicazione è di solito il giro tra un deploy fallito e il capire perché. I log in diretta accorciano quel giro: vedi la fase e la riga esatte in cui l'esecuzione si è rotta, dallo stesso workspace in cui scrivi chat, agenti, codice e dati. Poiché osFoundry è bring-your-own-key e local-first, la pipeline si adatta a un flusso in cui mantieni il controllo delle tue chiavi e dei tuoi dati, invece di affidare il processo di build a un fornitore di CI terzo con il suo prezzo per postazione e il suo posto dove conservare i tuoi log.
Funzionalità principali
- Ogni push esegue le stesse quattro fasi nell'ordine: install, lint, build, deploy
- La pipeline si ferma alla prima fase che fallisce, così una build rotta non va mai in deploy
- I log di ogni fase arrivano in diretta mentre l'esecuzione procede, non dopo che è finita
- Gli artefatti di build vengono conservati per versione, lasciando una traccia duratura di ciò che hai pubblicato
- Nessun servizio di CI separato, runner o YAML scritto a mano: è parte del workspace
Casi d’uso
- Sviluppatore solo: fai push di un'app e guarda install, lint e build in diretta, cogliendo una fase di lint fallita prima che qualcosa vada in deploy
- Piccolo team che pubblica app interne: affidati alla sequenza fissa install-lint-build-deploy perché nessuna build non revisionata o rotta raggiunga gli utenti
- Sviluppatore che fa il debug di un deploy: scorri gli artefatti conservati e i log in diretta di un'esecuzione passata per trovare la fase esatta in cui una versione si è rotta
Domande frequenti
Cosa viene eseguito quando faccio push di codice a un'app osFoundry?
Una pipeline fissa: installa le dipendenze, lint, build e poi deploy. Le fasi vengono eseguite nell'ordine e la pipeline si ferma alla prima che fallisce, così un lint o una build falliti non arrivano mai alla fase di deploy.
Posso vedere i log di build mentre un'esecuzione è in corso?
Sì. I log di ogni fase ti raggiungono in diretta man mano che l'esecuzione procede, così vedi l'output di install, lint e build in tempo reale invece di aspettare la fine dell'esecuzione e poi leggere un dump statico.
Le vecchie build vengono conservate dopo il deploy?
Sì. Gli artefatti delle build riuscite vengono conservati, così ogni versione che deployi lascia una traccia duratura a cui puoi tornare, invece di una build che sparisce una volta completata.