Skip to Content
TestingDeployment de app

Deployment de app

OpenFactory pode transformar repositório Git suportado em variant imutável de app, inicializar VM de replacement, fazer health-check e só então trocar rota do app depois que candidato estiver saudável. Serviços web e sites estáticos recebem URL em https://<slug>.apps.openfactory.tech quando caminho de ingress público está disponível.

Disponibilidade: pipeline de deployment e caminho de rota pública foram validados end to end. UI Apps e histórico de deployment não está pronta, jobs agendados são rejeitados e pass-through WebSocket/SSE ainda precisa teste de aceitação em produção dedicado. Trate URL retornada como utilizável só depois que status de deployment for live e seu próprio pedido succeeder.

O que um deployment faz

  1. Resolve revisão Git exata com credenciais de origem conectadas da conta.
  2. Prepara origem sem copiar credenciais Git ou histórico .git para imagem.
  3. Empacota app via OBS quando selecionado e suportado, ou usa hook de build de imagem.
  4. Constrói e inicializa variant fresh específica do app.
  5. Escreve valores de ambiente de runtime após boot, inicia serviço e roda health check.
  6. Troca rota do gateway e remove VM anterior só depois que novo candidato estiver saudável.

VM live é artefato de deployment. OpenFactory não instala, constrói nem edita origem dentro dela.

Deploy de app registrado

Registre origem uma vez:

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

Depois enfileire deployment:

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

deploy_app é assíncrono por default. Guarde app_id, deploy_id e build_id retornados e faça poll:

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

Deployment continua se cliente MCP der timeout. Não envie deployment duplicado só porque wait terminou. Verifique deployment existente primeiro.

Sucesso e falha

Resposta de fila bem-sucedida não prova que app está live. Exija tudo:

  • status de deployment é live;
  • estágio health-check passou;
  • URL retornada serve revisão esperada; e
  • checagem autenticada succeede quando visibility é private.

Em falha, registre stage, error, build_id e deploy_id com falha. Como cutover é health-gated, candidato com falha deve deixar rota saudável anterior no lugar.

Estratégia de build

use_obs=true exige caminho OBS saudável e suportado e falha fechado se indisponível. use_obs=false seleciona hook de build de imagem. Omitir argumento deixa serviço escolher OBS para projetos Node/static suportados e fallback para hook.

Só valores com prefixo público podem ser baked em variant. Segredos e outros valores de runtime pertencem ao ambiente criptografado de app e são aplicados após boot.

Testar app hospedado em outro lugar

Não precisa fazer deploy do app via OpenFactory para testá-lo. Qualquer URL alcançável da VM tester pode ser usada com cenário de app ou walk autônomo.

Limites atuais

  • Serviços web e sites estáticos são suportados; jobs agendados não.
  • UI de gerenciamento para histórico de app está pendente; status MCP é fonte da verdade.
  • Disponibilidade de preview depende de gateway de app, ingress wildcard, DNS e VM candidata.
  • Previews privados são owner-gated hoje; sharing de membro de organização não está implementado.
  • Rollback de checkpoint ainda não migrou para modelo de deployment imutável atual. Veja Checkpoints e rollback.

Relacionados