Despliegue de app

OpenFactory puede convertir un repositorio Git admitido en un variant de app inmutable, arrancar una VM de reemplazo, hacer health-check y conmutar la ruta de la app solo después de que el candidato esté sano. Los servicios web y sitios estáticos reciben una URL bajo https://<slug>.apps.openfactory.tech cuando la ruta de ingress pública está disponible.

Disponibilidad: el pipeline de despliegue y la ruta pública se han validado de extremo a extremo. La UI de Apps e historial de despliegue no está terminada, los jobs programados se rechazan y el passthrough WebSocket/SSE aún necesita una prueba de aceptación de producción dedicada. Trata una URL devuelta como utilizable solo después de que el estado de despliegue sea live y tu propia solicitud tenga éxito.

Qué hace un despliegue

Resuelve la revisión Git exacta con las credenciales de origen conectadas de la cuenta.
Prepara la fuente sin copiar credenciales Git ni historial .git en la imagen.
Empaqueta la app mediante OBS cuando se selecciona y está admitido, o usa el hook de compilación de imagen.
Compila y arranca un variant fresco específico de la app.
Escribe valores de entorno en runtime tras el arranque, inicia el servicio y ejecuta health check.
Conmuta la ruta del gateway y elimina la VM anterior solo después de que el candidato nuevo esté sano.

La VM en vivo es un artefacto de despliegue. OpenFactory no instala, compila ni edita fuente dentro de ella.

Desplegar una app registrada

Registra la fuente una vez:


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

Luego encola un despliegue:


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

deploy_app es asíncrono por defecto. Conserva el app_id, deploy_id y build_id devueltos y haz polling:


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

El despliegue continúa si un cliente MCP hace timeout. No envíes un despliegue duplicado solo porque terminó una espera. Comprueba primero el despliegue existente.

Éxito y fallo

Una respuesta de cola exitosa no prueba que la app esté en vivo. Exige todo lo siguiente:

el estado de despliegue es live;
la etapa de health check pasó;
la URL devuelta sirve la revisión esperada; y
una comprobación autenticada tiene éxito cuando la visibilidad es private.

En fallo, registra stage, error, build_id y deploy_id fallidos. Como el cutover está condicionado a salud, un candidato fallido debería dejar la ruta sana anterior en su sitio.

Estrategia de compilación

use_obs=true requiere una ruta OBS sana y admitida y falla cerrado si esa ruta no está disponible. use_obs=false selecciona el hook de compilación de imagen. Omitir el argumento deja que el servicio elija OBS para proyectos Node/estáticos admitidos y recurra al hook.

Solo valores con prefijo público pueden hornearse en un variant. Secretos y otros valores de runtime pertenecen al entorno cifrado de app y se aplican tras el arranque.

Probar una app hospedada en otro sitio

No necesitas desplegar una app mediante OpenFactory para probarla. Cualquier URL alcanzable desde la VM tester puede usarse con un escenario de app o un walk autónomo.

Límites actuales

Se admiten servicios web y sitios estáticos; los jobs programados no.
La UI de gestión de historial de app está pendiente; el estado MCP es la fuente de verdad.
La disponibilidad preview depende del gateway de app, ingress wildcard, DNS y la VM candidata.
Las previews privadas están restringidas al propietario hoy; el compartir con miembros de organización no está implementado.
El rollback por checkpoint aún no se migró a este modelo de despliegue inmutable. Consulta Checkpoints y rollback.