Skip to Content
TestingDeploy app

Deploy app

OpenFactory può trasformare un repository Git supportato in una variante app immutabile, avviare una VM sostitutiva, health-checkarla e commutare la route app solo dopo che il candidato è sano. Servizi web e siti statici ricevono un URL sotto https://<slug>.apps.openfactory.tech quando il percorso ingress pubblico è disponibile.

Disponibilità: pipeline deploy e percorso route pubblica sono stati validati end to end. L’UI Apps e cronologia deploy non è finita, i job schedulati sono rifiutati e pass-through WebSocket/SSE richiede ancora un test accettazione produzione dedicato. Tratta un URL restituito come utilizzabile solo dopo che lo stato deploy è live e la tua richiesta riesce.

Cosa fa un deploy

  1. Risolve la revisione Git esatta con le credenziali sorgente collegate dell’account.
  2. Prepara sorgente senza copiare credenziali Git o cronologia .git nell’immagine.
  3. Impacchetta l’app tramite OBS quando selezionato e supportato, o usa l’hook build immagine.
  4. Builda e avvia una variante app-specifica fresca.
  5. Scrive valori ambiente runtime dopo boot, avvia il servizio ed esegue health check.
  6. Commuta route gateway e rimuove la VM precedente solo dopo che il nuovo candidato è sano.

La VM live è un artefatto deploy. OpenFactory non installa, builda o modifica sorgente dentro di essa.

Deploy di un’app registrata

Registra la sorgente una volta:

create_app(
  name="my-shop",
  git_url="https://github.com/example/my-shop",
  branch="main",
  deployment_type="web-service",
  port=3000,
  visibility="private"
)

Poi accoda un deploy:

deploy_app(app_id="<app-id>")

deploy_app è asincrono di default. Conserva app_id, deploy_id e build_id restituiti e fai polling:

get_app_deploy_status(app_id="<app-id>", deploy_id="<deploy-id>")

Il deploy continua se un client MCP va in timeout. Non inviare un deploy duplicato solo perché un’attesa è finita. Controlla prima il deploy esistente.

Successo e fallimento

Una risposta coda riuscita non prova che l’app sia live. Richiedi tutto quanto segue:

  • stato deploy live;
  • stage health-check superato;
  • l’URL restituito serve la revisione attesa; e
  • un controllo autenticato riesce quando visibility è private.

In caso di fallimento, registra stage, error, build_id e deploy_id falliti. Poiché il cutover è gated su health, un candidato fallito dovrebbe lasciare la route sana precedente invariata.

Strategia build

use_obs=true richiede un percorso OBS sano e supportato e fallisce chiuso se quel percorso non è disponibile. use_obs=false seleziona l’hook build immagine. Omettere l’argomento lascia al servizio la scelta OBS per progetti Node/static supportati e fallback sull’hook.

Solo valori prefisso pubblico possono essere incorporati in una variante. Segreti e altri valori runtime appartengono all’ambiente app cifrato e sono applicati dopo boot.

Testare un’app hostata altrove

Non serve deployare un’app tramite OpenFactory per testarla. Qualsiasi URL raggiungibile dalla tester VM può essere usato con uno scenario app o una walk autonoma.

Limiti attuali

  • Servizi web e siti statici sono supportati; job schedulati no.
  • L’UI gestione cronologia app è pending, quindi lo stato MCP è fonte di verità.
  • Disponibilità preview dipende da gateway app, ingress wildcard, DNS e VM candidato.
  • Preview private sono gated owner oggi; condivisione membri organizzazione non implementata.
  • Rollback checkpoint non è ancora migrato a questo modello deploy immutabile. Vedi Checkpoint e rollback.

Correlati

Database gestitiDomini app personalizzati