CI/CD가 약속하는 것

CI/CD가 진짜 주는 것

CI/CD의 마케팅 문구는 더 빨리 출시하기야. 일부는 맞지만 가장 핵심적인 이익은 아니야. 가장 깊은 곳에 있는 이익은 신뢰야. 구체적으로, 세 가지 주장에 대한 신뢰지:

main 브랜치는 항상 출시 가능. 커밋이 main에 들어있다면, 팀이 합의한 모든 통과 조건을 넘겼다는 뜻이야. 누구든, 아무에게도 물어보지 않고, 언제든 배포할 수 있어.
빌드는 재현 가능. main에 있는 건 같은 소스 코드에서 깨끗한 머신으로 다시 빌드할 수 있어. '내 노트북에서는 됨' 따위는 없어.
실패가 빨리 드러남. 회귀가 새어나갔어도 다음 PR의 CI가 잡아줘. 피해 범위는 커밋 1개, 릴리스 1회가 아니야.

이 셋이 합쳐지면 소프트웨어를 변경하는 비용이 무너져. 자랑스러운 코드베이스와 무서운 코드베이스의 차이가 바로 이거야.

CI/CD가 주지 않는 것

CI/CD가 테스트를 대신 짜주지 않아. 코드베이스 구조를 마법처럼 깔끔하게 만들어주지도 않아. 테스트가 커버하지 않는 버그를 찾아주지도 않아. CI/CD는 규율을 증폭하는 기계야 — 규율이 있는 팀을 훨씬 빠르게 만들고, 너저분한 팀을 훨씬 빠르게 사고 치게 해. 뒤에 테스트 없는 파이프라인은 그냥 연극이야.

Code

'main은 출시 가능'이 브랜치 보호 규칙으로 보일 때·json

// settings.repositories.main.branch_protection (JSON view)
{
  "required_status_checks": {
    "strict": true,
    "contexts": ["ci / test", "ci / lint", "ci / type-check"]
  },
  "required_pull_request_reviews": {
    "required_approving_review_count": 1
  },
  "enforce_admins": true,
  "allow_force_pushes": false
}

Exercise

네가 가진 저장소에서 main 브랜치에 상태 확인을 최소 하나는 통과해야 한다는 브랜치 보호 규칙을 걸어. CI가 아직 없으면 'ok'라고 echo만 하는 아무 작업도 안 하는 워크플로를 일단 박아서 규칙이 강제할 게 있게 만들어 — 진짜 확인은 퀘스트 뒤에서 갈아치울 거야.

CI/CD가 진짜 주는 것

CI/CD가 주지 않는 것

Code

External links

Exercise

Progress

댓글 0