CI 실행 흐름

TypeScript CI/CD 경계 설계

GitHub Actions를 쓰면 자동화가 된다는 설명만으로는 부족하다. 어떤 path 변경에 어떤 job이 돌고, package manager cache가 어디에 잡히며, typecheck와 test matrix가 어떤 Node 버전을 커버하고, artifact와 secrets가 어디까지 노출되는지 명확해야 한다.

01

트리거 정의

push, pull request, tag, manual dispatch와 path filter를 배포 단위에 맞춘다.

모든 변경에 모든 job을 돌릴 필요는 없다
02

의존성 캐시

package manager lockfile과 Node 버전을 cache key에 넣어 재현성과 속도를 맞춘다.

잘못된 캐시는 이상한 빌드를 만든다
03

검증 job 분리

typecheck, lint, unit test, build, e2e를 실패 원인이 보이도록 분리한다.

하나의 거대한 job은 디버깅이 느리다
04

기준표 실행

지원 Node 버전이나 패키지 범위를 matrix로 나누고 fail-fast 정책을 정한다.

필수 범위만 넓힌다
05

배포 보호

artifact, environment approval, secrets, rollback을 배포 job에 연결한다.

PR에서 secret이 노출되지 않게 한다
cache
설치 속도와 재현성 lockfile hash와 Node 버전을 key에 포함해 잘못된 재사용을 막는다.
cache miss와 hit를 로그로 본다
기준표
여러 환경 검증 Node 버전, OS, package 범위를 병렬로 검증한다.
지원하지 않는 조합까지 넓히지 않는다
산출물
산출물 전달 빌드 결과, 테스트 리포트, coverage를 다음 job이나 배포에 넘긴다.
보존 기간을 정한다
secrets
민감정보 경계 배포 환경에서만 접근하고 PR 외부 기여자에게 노출하지 않는다.
로그 마스킹을 확인한다

자동화 확인

실패 위치 타입 오류, 테스트 실패, 빌드 실패가 각각 다른 job에서 선명하게 보이는지 확인한다.
캐시 키 lockfile 변경 시 의존성 캐시가 새로 잡히는지 확인한다.
배포 보호 production 배포가 승인과 secret 경계를 거치는지 확인한다.