Wdrażanie aplikacji

OpenFactory może zamienić obsługiwane repozytorium Git w immutable app variant, uruchomić zastępczą VM, wykonać health-check i przełączyć trasę aplikacji dopiero gdy kandydat jest zdrowy. Web services i static sites otrzymują URL pod https://<slug>.apps.openfactory.tech, gdy public ingress path jest dostępny.

Dostępność: deployment pipeline i ścieżka public route zostały zweryfikowane end to end. UI Apps i historii wdrożeń nie jest ukończone, scheduled jobs są odrzucane, a WebSocket/SSE pass-through nadal wymaga dedykowanego production acceptance test. Traktuj zwrócony URL jako użyteczny dopiero gdy deployment status to live i własne żądanie się powiedzie.

Co robi wdrożenie

Ustala dokładną rewizję Git przy użyciu connected source credentials konta.
Przygotowuje source bez kopiowania Git credentials ani historii .git do obrazu.
Pakuje aplikację przez OBS, gdy wybrano i jest obsługiwane, albo używa image build hook.
Buduje i uruchamia świeży app-specific variant.
Zapisuje runtime environment values po boot, uruchamia usługę i wykonuje health check.
Przełącza trasę gateway i usuwa poprzednią VM dopiero gdy nowy kandydat jest zdrowy.

Live VM to deployment artifact. OpenFactory nie instaluje, nie buduje ani nie edytuje source wewnątrz VM.

Wdróż zarejestrowaną aplikację

Zarejestruj source raz:


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

Następnie dodaj wdrożenie do kolejki:


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

deploy_app domyślnie działa asynchronicznie. Zachowaj zwrócone app_id, deploy_id i build_id oraz odpytuj:


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

Wdrożenie trwa dalej, jeśli klient MCP przekroczy limit czasu. Nie wysyłaj duplikatu wdrożenia tylko dlatego, że oczekiwanie się skończyło. Najpierw sprawdź istniejące wdrożenie.

Sukces i niepowodzenie

Udana odpowiedź z kolejki nie dowodzi, że aplikacja jest live. Wymagaj wszystkiego poniżej:

deployment status to live;
etap health-check zakończył się powodzeniem;
zwrócony URL serwuje oczekiwaną rewizję; oraz
uwierzytelnione sprawdzenie się powiedzie, gdy visibility to private.

Przy niepowodzeniu zapisz nieudany stage, error, build_id i deploy_id. Ponieważ cutover jest health-gated, nieudany kandydat powinien zostawić poprzednią zdrową trasę.

Strategia build

use_obs=true wymaga zdrowej, obsługiwanej ścieżki OBS i kończy się błędem (fails closed), gdy ta ścieżka jest niedostępna. use_obs=false wybiera image-build hook. Pominięcie argumentu pozwala usłudze wybrać OBS dla obsługiwanych projektów Node/static i wrócić do hooka.

Do variant można wbudować tylko wartości public-prefix. Secrets i inne runtime values należą do encrypted app environment i są stosowane po boot.

Testowanie aplikacji hostowanej gdzie indziej

Nie musisz wdrażać aplikacji przez OpenFactory, aby ją testować. Każdy URL osiągalny z tester VM można użyć ze scenariuszem aplikacji lub autonomous walk.

Obecne ograniczenia

Web services i static sites są obsługiwane; scheduled jobs nie.
UI zarządzania historią aplikacji jest w przygotowaniu; status MCP jest source of truth.
Dostępność preview zależy od app gateway, wildcard ingress, DNS i kandydata VM.
Private previews są dziś owner-gated; udostępnianie członkom organizacji nie jest zaimplementowane.
Checkpoint rollback nie został jeszcze przeniesiony na ten immutable deployment model. Zobacz Checkpoints and rollback.