Déploiement app

OpenFactory peut transformer un dépôt Git supporté en variant app immuable, démarrer une VM de remplacement, faire un health-check et basculer la route app seulement après que le candidat est sain. Les services web et sites statiques reçoivent une URL sous https://<slug>.apps.openfactory.tech lorsque le chemin ingress public est disponible.

Disponibilité : le pipeline de déploiement et le chemin route publique ont été validés bout en bout. L’UI Apps et historique de déploiement n’est pas terminée, les jobs planifiés sont rejetés, et le pass-through WebSocket/SSE nécessite encore un test d’acceptation production dédié. Traitez une URL renvoyée comme utilisable seulement après statut de déploiement live et succès de votre propre requête.

Ce qu’un déploiement fait

Résout la révision Git exacte avec les identifiants source connectés du compte.
Met en place la source sans copier identifiants Git ni historique .git dans l’image.
Empaquette l’app via OBS lorsque sélectionné et supporté, ou utilise le hook build image.
Construit et démarre un variant app neuf.
Écrit valeurs environnement runtime après boot, démarre le service et exécute un health check.
Bascule la route gateway et retire l’ancienne VM seulement après que le nouveau candidat est sain.

La VM live est un artefact de déploiement. OpenFactory n’installe, ne build ni ne modifie la source à l’intérieur.

Déployer une app enregistrée

Enregistrez la source une fois :


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

Puis mettez en file un déploiement :


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

deploy_app est asynchrone par défaut. Conservez app_id, deploy_id et build_id renvoyés, et interrogez :


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

Le déploiement continue si un client MCP expire. Ne soumettez pas un déploiement en double uniquement parce qu’une attente s’est terminée. Vérifiez d’abord le déploiement existant.

Succès et échec

Une réponse de file réussie n’est pas une preuve que l’app est live. Exigez tout ce qui suit :

statut de déploiement live ;
l’étape health-check a réussi ;
l’URL renvoyée sert la révision attendue ; et
une vérification authentifiée réussit lorsque la visibilité est private.

En échec, enregistrez stage, error, build_id et deploy_id en échec. Comme la bascule est conditionnée au health, un candidat en échec devrait laisser la route saine précédente en place.

Stratégie de build

use_obs=true exige un chemin OBS sain et supporté et échoue fermé si indisponible. use_obs=false sélectionne le hook build image. Omettre l’argument laisse le service choisir OBS pour projets Node/statiques supportés et retomber sur le hook.

Seules des valeurs à préfixe public peuvent être intégrées dans un variant. Secrets et autres valeurs runtime appartiennent à l’environnement app chiffré et sont appliqués après boot.

Tester une app hébergée ailleurs

Vous n’avez pas besoin de déployer une app via OpenFactory pour la tester. Toute URL joignable depuis la VM testeur peut être utilisée avec un scénario app ou une walk autonome.

Limites actuelles

Services web et sites statiques sont supportés ; jobs planifiés non.
L’UI de gestion pour l’historique app est en attente ; le statut MCP fait autorité.
La disponibilité preview dépend gateway app, ingress wildcard, DNS et VM candidat.
Les previews privées sont limitées au propriétaire aujourd’hui ; partage membre organisation non implémenté.
Le rollback checkpoint n’a pas encore migré vers ce modèle de déploiement immuable. Voir Checkpoints et rollback.