CI/CD 가 약속하는 것

CI/CD 가 진짜 사주는 것

CI/CD 의 marketing pitch 는 더 빨리 ship 이야. 일부는 맞지만 가장 깊은 이익은 아니야. 가장 깊은 이익은 신뢰 야. 구체적으로, 세 가지 주장에 대한 신뢰:

Main 은 항상 ship 가능. Commit 이 main 에 살고 있다면, 팀이 합의한 모든 gate 를 통과한 거야. 아무나, 아무에게도 안 묻고, 아무 때나 deploy 할 수 있어.
Build 은 재현 가능. Main 에 있는 건 같은 source 에서 깨끗한 머신으로 rebuild 가능해. '내 노트북에서는 됨' 없음.
Failure 가 빨리 드러남. Regression 이 새어나갔어도 다음 PR 의 CI 가 잡아. Blast radius 는 1 commit, release 1 회가 아니야.

이 셋이 합쳐지면 소프트웨어 변경 비용이 무너져. 자랑스러운 codebase 와 무서운 codebase 의 차이가 이거야.

CI/CD 가 안 사주는 것

CI/CD 가 test 를 대신 짜주지 않아. Codebase architecture 를 마법처럼 깔끔하게 만들어 주지도 않아. Test 가 cover 안 하는 bug 를 찾아주지도 않아. CI/CD 는 discipline 증폭기야 — discipline 있는 팀을 훨씬 빠르게 하고, 너저분한 팀을 훨씬 빠르게 사고 치게 해. 뒤에 test 없는 pipeline 은 연극이야.

Code

'main 은 shippable' 이 branch protection rule 로 보일 때·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

소유한 repo 에서 main 에 status check 최소 하나는 통과해야 한다는 branch protection rule 을 걸어. CI 가 아직 없으면 'ok' 라고 echo 만 하는 no-op workflow 를 일단 박아서 rule 이 enforce 할 게 있게 만들어 — 진짜 check 는 quest 뒤에서 갈아치울 거야.