성공한 빌드는 신성해

main 브랜치가 항상 성공해야 하는 건 팀의 약속이야

CI/CD 환경에서 가장 중요한 문화적 규칙은 하나야. main 브랜치를 망가뜨리지 마. main이 실패 상태가 되면 이걸 고치는 게 팀의 최우선 과제야. 새로운 기능 마무리도 아니고 3시 회의도 아니야. 오직 빌드를 고치는 게 우선이야.

당연한 말처럼 들리지만 끊임없이 어겨지곤 해. 흔하게 발생하는 실패 사례는 이런 거야.

1시간 전에 CI가 성공했던 PR을 병합했는데, 그 사이 다른 PR이 먼저 반영돼서 조합이 깨지는 경우. 이건 strict required-status-check 설정이 빠져 있어서 생기는 문제야.
'그냥 문서 수정이니까'라며 관리자 권한으로 CI를 우회하는 경우.
CI의 간헐적 실패를 새로운 정상 상태로 받아들이는 경우. 엔지니어들이 '다시 실행하면 되겠지'라며 실패 상태를 무시하기 시작해.
테스트를 고치는 대신 비활성화해버리는 경우.

main을 성공 상태로 유지하는 원칙

브랜치 보호: 병합 전에 CI 성공을 요구하고, strict(새 병합 기준에서 재실행)을 요구해.
병합 대기열: 병합을 직렬화해서 각 PR이 실제로 반영될 기준에 대해 테스트를 받도록 만들어.
간헐적 실패를 P0로 다뤄: 어떤 테스트도 무작위로 실패하면 안 돼. 간헐적 실패를 고치거나 테스트를 삭제해. 세 번째 선택지는 없어.
'main을 망가뜨렸으면 main을 고친다' — 망가진 커밋을 푸시한 엔지니어가 즉시 되돌리거나 빠른 수정의 담당자가 돼.

Code

병합 대기열 설정 — GitHub 기본 기능·yaml

# Workflow that runs on the merge queue
name: ci
on:
  pull_request:
  merge_group:    # GitHub merge queue event
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: pytest -q

Exercise

저장소에서 가장 최근에 실패한 main 빌드를 찾아봐 (Actions 탭 → main → 실패 필터). 실패 원인을 분석해. 어떻게 반영된 거야? strict required-status-check가 켜져 있었어? 다시 실행으로 가려진 간헐적 실패였어? 뭘 바꿀지 한 문단으로 회고를 작성해.

main 브랜치가 항상 성공해야 하는 건 팀의 약속이야

main을 성공 상태로 유지하는 원칙

Code

External links

Exercise

Progress

댓글 0