# Gateway release controller `release-controller`는 Gateway API·frontend·orchestrator와 분리된 PM2 프로세스입니다. 관리자 GUI가 `GatewayReleaseOperation`을 만들면 controller가 선택 commit을 고정하고 다음 순서로 전환합니다. 1. commit 전용 worktree를 준비하고 frozen lockfile로 의존성을 설치합니다. 2. `release-manifest.json`의 protocol, component와 실제 migration head를 확인합니다. 3. Gateway API와 frontend를 빌드하고 gateway migration을 적용합니다. 4. 기존 `sammo:gateway-api`, `sammo:gateway-frontend`, `sammo:gateway-orchestrator`를 중지하고 새 worktree에서 시작합니다. 5. 두 HTTP endpoint와 세 PM2 process가 모두 준비된 경우에만 현재·이전 릴리스 상태를 게시합니다. 실패하면 이전 세 프로세스를 복구합니다. Controller는 PM2 자식으로 실행되지만 자신의 `args=daemon`과 PM2 identity를 Gateway process 환경에 전달하지 않습니다. 이 값이 frontend 정의를 덮으면 Vite가 의도한 preview port 대신 기본 개발 port로 실행될 수 있으므로, process `online` 여부뿐 아니라 Gateway API와 frontend HTTP readiness를 모두 확인합니다. ## 환경 변수 - `GATEWAY_DATABASE_URL`: Gateway PostgreSQL URL입니다. 필수입니다. - `REDIS_URL`: Gateway API와 orchestrator가 사용할 Redis URL입니다. 필수입니다. - `GATEWAY_DB_SCHEMA`: Gateway schema이며 기본값은 `public`입니다. - `RELEASE_CONTROLLER_WORKSPACE_ROOT`: Git checkout입니다. - `RELEASE_CONTROLLER_WORKTREE_ROOT`: commit worktree 상위 경로입니다. - `GATEWAY_API_PORT`, `GATEWAY_FRONTEND_PORT`, `GATEWAY_BASE_PATH`: readiness와 frontend build 계약입니다. - `RELEASE_CONTROLLER_POLL_MS`, `RELEASE_CONTROLLER_READINESS_TIMEOUT_MS`: queue poll과 준비 제한 시간입니다. - `TURBO_CACHE_DIR`: 선택 사항인 공유 local cache 경로입니다. 없으면 원래 `RELEASE_CONTROLLER_WORKSPACE_ROOT/.turbo/release-cache`를 사용합니다. 상대 경로는 원래 workspace 기준으로 해석합니다. - `RELEASE_TURBO_CONCURRENCY`: Turbo worker 수입니다. 기본값 1은 실행 중인 game/Gateway process와 4 GiB runtime을 공유하는 production cold build의 OOM을 피합니다. 더 큰 격리 build host에서만 측정 후 2 이상으로 올립니다. 비밀값은 Git에서 제외된 환경 파일 또는 process 환경으로 전달해 주세요. `VITE_*`에는 공개 URL만 넣어 주세요. Self-upgrade는 controller의 script와 cwd만 선택 commit worktree로 바꿉니다. `RELEASE_CONTROLLER_WORKSPACE_ROOT`는 원래 Git checkout을 유지해야 합니다. 이를 controller artifact worktree로 바꾸면 아직 게시된 release state가 없는 최초 DEPLOY의 rollback이 frontend build가 없는 controller worktree를 이전 Gateway로 오인할 수 있습니다. ## 설치와 실행 먼저 controller가 읽을 Gateway schema를 migration하고 의존 package를 함께 빌드합니다. ```sh pnpm install --frozen-lockfile pnpm exec turbo run build --filter=@sammo-ts/release-controller --concurrency=1 --ui=stream pnpm --filter @sammo-ts/infra prisma:migrate:deploy:gateway pnpm --filter @sammo-ts/release-controller start ``` 운영에서는 마지막 명령 대신 `sammo:release-controller`라는 PM2 process로 `app/release-controller/dist/index.js daemon`을 실행해 주세요. 상태와 queue 한 건 처리는 다음 CLI로 확인할 수 있습니다. ```sh pnpm --filter @sammo-ts/release-controller status pnpm --filter @sammo-ts/release-controller run-once ``` ## Controller self-upgrade 이 명령은 현재 daemon과 별개의 CLI process에서 실행됩니다. 대상 worktree를 빌드하고 gateway migration을 적용한 뒤 `sammo:release-controller`만 새 worktree로 전환합니다. 새 daemon 시작에 실패하면 이전 definition을 복구합니다. ```sh pnpm --filter @sammo-ts/release-controller build pnpm --filter @sammo-ts/release-controller self-upgrade BRANCH main # 또는 pnpm --filter @sammo-ts/release-controller self-upgrade COMMIT ``` Database migration은 일반적으로 되돌리지 않습니다. 이전 애플리케이션으로 rollback하려면 새 schema와의 하위 호환성을 릴리스 전에 확인해 주세요. `release-manifest.json`의 `controllerProtocol`이 올라간 릴리스는 controller를 먼저 self-upgrade해야 합니다. Protocol 2는 `GatewayReleaseLog` 진행 로그 저장을 요구합니다. 구형 controller로 새 Gateway만 배포하면 관리자 화면과 controller의 기능이 어긋날 수 있으므로, 일반 배포의 manifest protocol 검사를 우회하지 마세요. Self-upgrade CLI만 다음 protocol을 허용하며 schema head와 component는 동일하게 검증합니다.