Guida al monorepo # Come eseguire il deploy di un monorepo sulla piattaforma cloud Cloud Noce? Guida al deploy di più servizi da un unico repository in Cloud Noce: configura cartella root, percorso del Dockerfile, contesto di build e percorsi monitorati, poi pubblica con la CLI. risposta breve In Cloud Noce, crea un servizio separato per ogni applicazione del monorepo, ad esempio `apps/web`, `apps/api` e per ogni worker, crea un **servizio separato** sulla [piattaforma cloud Cloud Noce (PaaS)](/products/paas) . Tutti i servizi possono collegarsi allo stesso repository e branch. La cartella root determina dove rilevare e compilare ogni servizio; i percorsi monitorati evitano deploy non necessari degli altri servizi. Ultima revisione:6 settembre 2026 ## Il modello monorepo in Cloud Noce Un repository può contenere più servizi Cloud Noce. Ogni servizio ha comandi di build e avvio, variabili, domini, numero di istanze e versioni di release indipendenti; puoi gestirli tutti nello stesso progetto e ambiente. ``` repo/ ├── apps/ │ ├── web/ # servizio web │ └── api/ # servizio API ├── packages/ │ └── shared/ # pacchetto condiviso ├── package.json └── pnpm-lock.yaml ``` ## Configura correttamente i tre campi di build - **Cartella root:** Percorso della cartella del servizio rispetto alla root del repository; per l'API usa `apps/api`. Il rilevamento dello stack e l'esecuzione dei comandi di build e avvio partono da questa cartella. - **Percorso del Dockerfile:** Percorso del file relativo alla root del repository, per esempio `apps/api/Dockerfile`. Un Dockerfile specificato esplicitamente ha sempre la precedenza sul rilevamento automatico. - **Contesto di build:** Solo per l'uso con un Dockerfile; il valore `.` rende accessibili i lockfile e i pacchetti condivisi nella root tramite `COPY` . Se il campo è vuoto, il contesto coincide con la «cartella root». ## Impostazione consigliata per workspace con pacchetti condivisi Se per la build l'applicazione ha bisogno di un lockfile o di pacchetti esterni alla propria cartella, tieni il Dockerfile nella cartella dell'app e imposta il «contesto di build» sulla root del repository. ``` # Campi di configurazione della build nel pannello Cloud Noce Cartella root: apps/api Percorso Dockerfile: apps/api/Dockerfile Contesto di build: . Percorsi monitorati: apps/api/** packages/shared/** pnpm-lock.yaml ``` Nel Dockerfile, i percorsi `COPY` sono relativi al «contesto di build». Se non hai un Dockerfile, Cloud Noce esegue Nixpacks o il builder dello stack integrato dalla «cartella root» e ignora il contesto di build personalizzato. Un progetto che dipende da file nella root richiede quindi in genere un Dockerfile con il contesto impostato sulla root del repository. ## Percorsi monitorati e deploy automatico Per un servizio collegato a Git, un push sul branch collegato avvia una nuova build solo se almeno un file modificato corrisponde ai «percorsi monitorati». Se l'elenco è vuoto, ogni push genera un deploy. - `apps/api` Include tutti i file in questo percorso. - `apps/api/**` Corrisponde a qualsiasi profondità sotto questo percorso. - `apps/*` Accetta solo una parte del percorso e non copre i file profondi. - Aggiungi pattern separati per lockfile, configurazione nella root e pacchetti condivisi. - Se GitHub non fornisce un elenco affidabile dei file modificati in un push molto grande, Cloud Noce ricostruisce il servizio per evitare di saltare una release. ## Configura ed esegui il deploy con Gerdoo CLI Per un'origine locale, la CLI comprime l'intero repository specificato e imposta la directory root su`--root-dir` . ``` cd repo gerdoo deploy . \ --name api \ --root-dir apps/api \ --dockerfile apps/api/Dockerfile \ --build-context . \ --port 8080 ``` Per un servizio Git esistente, puoi aggiornare le impostazioni del monorepo e i percorsi monitorati: ``` gerdoo service update api \ --root-dir apps/api \ --dockerfile apps/api/Dockerfile \ --build-context . \ --watch-path 'apps/api/**' \ --watch-path 'packages/shared/**' \ --watch-path pnpm-lock.yaml ``` ## Checklist per il deploy - Imposta una cartella root e un percorso di health check distinti per ogni servizio. - Aggiungi i pacchetti condivisi e i lockfile ai percorsi monitorati di tutti i servizi che li usano. - Imposta le variabili condivise a livello di progetto o ambiente e i valori segreti specifici a livello di servizio. - Modifica solo il servizio web e verifica che l'API non venga ricompilata senza motivo. - Modifica il pacchetto condiviso e verifica che tutti i servizi che lo usano vengano pubblicati. - Controlla i log di build per verificare che siano stati selezionati il builder, il Dockerfile e il contesto previsti. - Esegui il rollback di ogni servizio separatamente e verifica la comunicazione tra i servizi. ## Domande frequenti ### Devo creare un servizio per ogni applicazione nel monorepo? Sì. In Cloud Noce, ogni applicazione web, API, worker o processo pianificato è un servizio. Collega ogni servizio allo stesso repository e branch, impostando la cartella root e i percorsi monitorati corretti. ### Qual è la differenza tra «cartella root» e «contesto di build»? La «cartella root» contiene il servizio ed è la base per rilevare lo stack ed eseguire i comandi di build. Il «contesto di build» serve solo quando usi un Dockerfile e determina quali parti del repository sono accessibili a COPY. ### A quale cartella è relativo il percorso del Dockerfile? Il percorso è relativo alla root del repository, non alla «cartella root» né al «contesto di build». Per esempio: apps/api/Dockerfile. ### Quali pattern supportano i percorsi monitorati? Un percorso semplice come apps/api funziona come prefisso. * corrisponde a una parte del percorso, ** attraversa più cartelle e ? corrisponde a un singolo carattere. Per un pacchetto condiviso, aggiungi anche packages/**.