Portal Delivery Flow

Portal Delivery Flow

fractalops-portal source/build ownership lives in private repo yamonco/fractalops-frontend. This control-plane repo keeps backend contracts, runtime automation, and GitOps desired state only.

Canonical Flow

1. yamonco/fractalops-frontend:portal 변경
2. frontend repo quality/build 검증
3. frontend repo portal image build/push
4. frontend workflow opens/updates the control-plane GitOps pin change
5. control-plane main 반영
6. Argo CD 가 Git 변화를 감지하고 rollout

Local Commands

Run frontend checks in yamonco/fractalops-frontend, not here:

• pnpm run lint:frontend:ci
• pnpm run portal:check
• pnpm run portal:build

This repo has no local Portal release command. Normal promotion path is: frontend main push -> frontend GitHub Actions -> control-plane GitOps pin commit -> Argo sync.

CI Flow

GitHub Actions workflow:

• yamonco/fractalops-frontend:.github/workflows/portal-gitops-release.yml

이 workflow는:

1. portal 검사
2. portal 빌드
3. GHCR 이미지 push
4. Helm values.yaml image pin (tag + digest) commit

즉 CI도 deploy 자체를 하지 않는다.
배포는 여전히 Argo CD 가 수행한다. 즉 사람은 kubectl apply 나 수동 rollout을 하지 않고, Git 변경만 만든다.

Design Rules

• deployment.yaml 는 chart template 안에서 image values를 읽는다.
• 실제 promotion pin은 Helm values.yaml 의 tag + digest 만 바꾼다.
• tag는 YYYYMMDD-HHMM-<git-sha> 형태의 source-correlated immutable tag를 쓴다.
• digest는 CI가 실제 push 결과에서 회수한 sha256:... 값을 기록한다.
• local verification은 astro dev 대신 production server entry로 확인한다.
• image build는 multi-stage Dockerfile을 쓴다.

Why

이 구조를 쓰면:

• dev server 와 production server 차이를 줄일 수 있고
• image build 결과가 local/CI에서 같아지고
• GitOps drift를 줄이며
• 누가 봐도 Argo CD 가 최종 deploy owner라는 사실이 명확해진다.