AladdinAI — CI/CD, poziomy aplikacji i hosting

Kanoniczny przepływ wdrożeń obowiązujący wszystkie aplikacje zespołu. Kod przechodzi bramkę testów, potem staging (pełna wierność, prywatnie), potem publiczne demo na danych syntetycznych, a na końcu — po potwierdzeniu przez człowieka — produkcję.

1 · Trzy poziomy aplikacji — gdzie ląduje produkcja

private

Projekty własne / narzędzia osobiste
Produkcja
VM sexybabe + własna domena kenzan.dev
(opcjonalnie prywatny Firebase)
Dostęp
prywatny
Demo
zwykle brak
Staging
opcjonalny

business — aladdinai — customer

Aplikacje dla klientów · np. OfferAgent
Produkcja
Google Cloud — VM jako baseline dla prostych aplikacji; Cloud Run, gdy aplikacja realnie potrzebuje jego infrastruktury (wtedy płacimy)
Dostęp
klient — Firebase Auth + allowlista
Demo
TAK — publiczne <app>demo.web.app
Staging
wymagany

business — aladdinai — internal

Narzędzia wewnętrzne · DataAgent, Mag-Auto
Produkcja
VM w piwnicy — dostęp tylko przez VPN, bezpośredni dostęp do bazy danych
Dostęp
VPN
Demo
TAK — publiczne (jedyna publiczna powierzchnia)
Staging
wymagany

Poziom ustalamy na starcie projektu i zapisujemy w PROJECT.md oraz w projects-registry.

2 · Kanoniczny przepływ — od kodu do produkcji

KOD ŚRODOWISKA git push branch: staging / main CI — bramka testów pytest + build frontendu BEZ auto-deployu 1 · STAGING — prawdziwa bramka QA • prywatny · pełna wierność produkcji • uruchamia to, co prod: cli_pool, watchdogi, research cen, pełna estymacja • pełny przebieg na danych referencyjnych • regres dokładności = STOP 2 · DEMO — publiczna próba generalna • publiczne · wyłącznie dane syntetyczne • tryb ograniczony (bez LLM / bez danych klienta) • sprawdza: build, UX, deploy — nie logikę ryzykowną • to NIE jest pierwszy test — tylko rehearsal wchodzi tu tylko kandydat do wydania 3 · PRODUKCJA — promocja • zawsze potwierdzenie człowieka • merge staging → main + tag vX.Y.Z • backup DB + katalogu (.bak-timestamp) • ścieżka wycofania ustalona PRZED wdrożeniem • weryfikacja po wdrożeniu: /health + akcja UI 4 · po wydaniu: odśwież DEMO do wydanego tagu Każde środowisko odpowiada: GET /health → {status, version, sha, env}

3 · Przykład wdrożony — OfferAgent (poziom: customer)

ŚrodowiskoAdresRuntimeKodDane
staging („X")offeragent-x.web.app VM :8024 (systemd)gałąź stagingkopia robocza
demoofferagentdemo.web.app Cloud Run offeragent-demotag kandydatasyntetyczne (demo_seed/)
produkcjaofferagent.web.app VM :8020 przez Cloud Run proxygałąź main (tag)dane klienta

4 · Reguły nienaruszalne

Nigdy auto-deploy z CICI tylko testuje. Wdrożenie zawsze potwierdza człowiek.
Nigdy danych klienta w demoDemo = wyłącznie dane syntetyczne z demo_seed/.
Nigdy restartu w trakcie liczeniaSprawdź journalctl przed restartem usługi z długimi zadaniami.
Wycofanie przed promocjąCloud Run → rollback rewizji. VM → przywrócenie .bak-<timestamp>.
Wdrażaj wszystkie warstwyFrontend przeciw staremu backendowi = przyciski zwracające 404.
Wersja widocznaBUILD_VERSION + BUILD_SHA przy każdym wdrożeniu.