출시 게이트 (Ship Gate)
여기의 모든 규칙은 명백한 검사가 한 번 거짓 통과(false pass)를 반환했기 때문에 존재합니다. 주장을 하기 전에 게이트를 실행하고, 주장한 후에는 실행하지 마세요.
구체적인 내용은 여러분의 스택에 맞게 조정하세요. 핵심 원칙인 '무엇이 이 주장을 거짓으로 만들 수 있는가?' 는 모든 상황에 적용 가능합니다.
주장 규칙
프로덕션에 대한 주장은 프로덕션을 직접 질의해야 합니다.
통과하는 테스트는 프로덕션이 아닙니다. 병합된 PR은 프로덕션이 아닙니다. 녹색(green) 배포는 프로덕션이 아닙니다. 이 모든 것은 여러분이 주장하는 시스템과는 다른 시스템에 대한 주장입니다.
아무도 결과를 직접 눈으로 확인하지 않았다면, 그것은 '검증됨'이 아닙니다. 대신 실제로 확인한 내용을 말하세요.
배포 검증
- 실제로 배포를 트리거하는 것이 무엇인지 알아두세요. Git 통합 호스트에서는 CLI 호출이 아니라 푸시(push)입니다. 프로젝트가 푸시로 배포될 때 CLI로 배포하면 사용자가 받는 빌드와 다른 빌드가 생성됩니다.
- 프로젝트를 소유한 계정을 확인하세요. 로컬에 로그인된 CLI가 프로덕션 프로젝트를 소유하지 않은 개인 계정으로 인증될 수 있습니다. 그러면 모든 명령이 조용히 잘못된 대상을 대상으로 성공합니다.
- 배포된 SHA에 대한 커밋 상태로 검증하고, 대시보드 한눈에 보는 것으로 검증하지 마세요.
- 단순히 'READY' 상태인 배포가 아니라 현재 프로덕션인 배포를 확인하세요. 여러 개가 동시에 'READY' 상태일 수 있습니다.
- 엣지/서버리스 함수는 앱과 별도로 배포됩니다. 병합된 PR이 엣지 함수를 배포하지는 않습니다. 버전을 명시적으로 확인하세요.
- 클라이언트 전용 변경 사항은 함수 배포가 필요 없을 수 있습니다. 절대 오지 않을 배포를 기다리지 마세요.
- 버전을 주장하기 전에 실시간 매니페스트를 다시 가져오세요. 병렬 작업이 여러분 아래에서 버전을 변경할 수 있습니다.
CI 검증
- 모든 필수 컨텍스트에 대해 게이트를 실행하고, 첫 번째 녹색(green) 컨텍스트만으로 게이트하지 마세요.
- 파이프 명령(piped command)에 게이트를 걸지 마세요.
some-check | tail은tail의 종료 코드를 보고하여 실제 실패를 가립니다.PIPESTATUS가 없는 셸(zsh는 bash와 다릅니다)에서는 이 실수를 하기 쉽습니다. 명령 자체의 상태를 확인하세요. steps: 0은 작업이 실행되지 않았다는 뜻이지, 통과했다는 뜻이 아닙니다. Checks API는 아무 작업도 하지 않은 작업에 대해 결론(conclusion)을 보고할 수 있습니다.- 단계 없이 의심스럽게 빠른 실패는 보통 청구(billing) 또는 권한(permissions) 문제이지 YAML 문제가 아닙니다.
- 실패한 작업만 다시 실행하면 브랜치의 오래된 스냅샷을 재생합니다. 먼저 브랜치를 업데이트한 후 다시 실행하세요.
- Checks 목록은 생성되지 않은 작업을 생략합니다. 실패가 없다는 것은 통과의 증거가 아닙니다.
gh pr create는 명시적인--base가 필요합니다. 그 주변의 연결된 heredoc는 조용히 실패할 수 있습니다.
타입 및 린트 게이트
- 대규모 TypeScript 프로젝트는 증가된 Node 힙이 필요할 수 있습니다. 그렇지 않으면
tsc가 코드 오류처럼 보이는 방식으로 중단됩니다. - 타입 검사기와 린터가 실제로 커버하는 디렉토리를 알아두세요. 엣지 함수 디렉토리는 종종 둘 다에서 제외됩니다. 다른 런타임에서 실행된다면, 해당 런타임의 자체 검사기로 확인하세요. 테스트 작업은 타입 게이트가 아닙니다.
- 작업 디렉토리가 아닌 워크트리(worktrees)나 클린 체크아웃(clean checkouts)에서 빌드하세요. 커밋되지 않은 변경 사항이 포함된 상태에서 빌드하지 마세요.
데이터베이스
- 절대 프로덕션에 대해 스키마를 푸시하거나 마이그레이션을 임의로 실행하지 마세요. 프로젝트가 선택한 검토된 경로를 통해 스키마를 한 번만 적용하세요.
- 실제 데이터베이스에 대해 새 저장 프로시저를 호출한 후에야 신뢰하세요. 모의(mock)는 실제 타입과 실제 모호성에서만 나타나는 런타임 오류를 숨깁니다.
- 테스트 스위트가 데이터베이스를 전역적으로 모의(mock)한다면, 통과하는 단위 테스트는 데이터베이스에 대해 아무것도 증명하지 않습니다.
- 트리거 관리 열(trigger-managed column)에 대해 절대 compare-and-set을 수행하지 마세요. 트리거가 쓰기 아래에서 값을 변경합니다.
- 병합하기 전에 프로덕션 데이터에 대한 변경 사항의 영향 범위를 측정하세요. 로컬 시드(seed)에 비해 좁아 보이는 필터가 실제 행(row)의 매우 다른 비율과 일치할 수 있습니다.
환경 함정
- 머신의 시간대를 절대 가정하지 말고
date를 실행하세요. 날짜 종속 테스트는 오프셋(offset)에서 실패하며, 그 실패는 코드 버그처럼 보입니다. - 설정되지 않은 git 신원(identity)은 배포를 차단하고 관련 없는 네트워크 오류로 표면화될 수 있습니다.
- 호스트 환경 변수는 인라인 할당보다는 파일에서 설정하세요. 셸과 CLI는 값에 보이지 않게 개행 문자(trailing newlines)를 포함하여 값을 손상시킬 수 있습니다.
- 예약된 작업의 성공은 작업 효과의 성공이 아닙니다.
succeeded를 보고하는 실행기는 호출이 반환되었음을 의미할 뿐, 작업이 수행되었음을 의미하지는 않습니다. 효과를 검증하세요.
출력
각 게이트의 상태를 PASS (근거) 또는 NOT CHECKED (이유) 형식으로 명시하세요.
게이트가 실행되지 않았는데 실행된 것처럼 암시하지 마십시오. 어떤 게이트라도 실패하거나 확인되지 않은 경우, 변경 사항이 검증되지 않았음을 명확히 말하세요. 주장을 보류하는 것이 올바른 행동입니다.