React 빌드와 배포

CI/CD 기초: 검사 순서와 배포 차단

프론트엔드 CI/CD는 배포 버튼을 줄이는 데서 끝나지 않습니다. 검사 순서와 preview 확인, 실패 차단 기준이 팀의 품질선을 만듭니다.

01

검사 파이프라인

lint, unit test, build, preview deploy, release approval을 PR 단계에 배치해 합치기 전 실패를 먼저 드러냅니다.

빌드 산출물
02

캐시와 환경 변수

package cache는 속도를 줄이고, artifact는 결과물을 남기며, secret 권한은 preview와 production 배포를 분리해 사고 범위를 줄입니다.

호스팅 경로
03

preview 배포 확인

preview URL에서 라우팅, API 환경 변수, 정적 asset 경로를 열어 봐야 로컬 빌드가 감춘 배포 문제를 PR 안에서 잡을 수 있습니다.

릴리스 확인
04

릴리스 로그와 승인

CI 로그, preview URL, 빌드 산출물, 승인자를 릴리스 기록으로 남기면 어떤 변경이 어떤 검사 뒤 배포됐는지 추적할 수 있습니다.

release log
CI 단계
lint, test, build가 PR마다 같은 순서로 실행된다 검사 순서가 바뀌면 빠르게 실패할 수 있는 lint가 늦어져 대기 시간이 길어집니다.
lint/test/build
배포 권한
preview secret과 production secret을 분리한다 PR에서 production 토큰을 바로 쓰지 않으면 실험 브랜치가 실제 배포를 건드릴 가능성을 줄입니다.
secret
preview URL
배포된 화면에서 라우팅과 asset 경로를 직접 연다 빌드는 통과했지만 base path나 환경 변수가 달라지는 문제는 preview 화면에서 가장 빨리 드러납니다.
릴리스 통과 기준

CI/CD에서 확인할 장면

PR 검사 통과 코드 변경 뒤 lint, test, build가 모두 통과하고 preview URL이 댓글이나 배포 기록에 남습니다.
빌드 실패 차단 타입 오류, 테스트 실패, 환경 변수 누락이 있으면 merge나 production 배포가 멈춰야 합니다.
배포 증적 artifact, commit hash, preview URL, 승인자를 남기면 배포 후 문제를 특정 변경으로 되돌려 볼 수 있습니다.

빌드 배포 점검

질문: 어떤 실패가 merge 전, preview 전, production 전에서 각각 멈춰야 하는가
순서: lint/test/build -> artifact 저장 -> preview 확인 -> 승인 후 배포
위험: 환경 변수와 라우팅 확인이 없는 배포는 빌드 성공 뒤에도 빈 화면을 만들 수 있습니다.