Continuous Integration 가 뭐야

멈추지 않는 integration

Continuous Integration 는 모든 변경이 자주 — 보통 개발자 한 명당 하루 여러 번 — 공유 main branch 로 merge 되고, 매 merge 마다 자동화된 build / test / lint sequence 가 돌아가는 거야. 핵심 단어는 continuous. nightly 아니야. weekly 아니야. 매 push, 매 PR, 매 commit.

이 원칙은 도구보다 오래됐어. Grady Booch 가 1991 년에 이 표현을 만들었어. 아이디어 자체는 더 오래됐고: 안 merge 된 작업을 쌓아두면 결국 merge 가 작은 고고학 프로젝트로 변해. CI 는 비용을 뒤집어 — 매 push 마다 작은 비용을 내고, release 때 거대한 비용 한 번을 안 내는 거지.

자동화된 CI run 이 실제로 하는 일

Checkout — test 할 commit 정확히 그거 가져오기.
Runtime 세팅 — Python, Node, JDK, 프로젝트가 필요한 거, pinned 된 version 으로.
Dependencies 설치 — 보통 cache 써서 두 번째 run 은 빨라.
Lint, type-check, format-check — 빠른 static gate.
Test — unit, integration, 때로는 end-to-end.
Report — green 아니면 red, log 와 artifact 까지.

결과물은 commit 당 1 bit 야: 이 변경 merge 해도 안전 vs 이 변경 깨졌음. 나머지 (log, artifact, coverage report) 는 그 bit 둘레의 장식이야.

Code

가장 작은 의미 있는 CI workflow·yaml

# .github/workflows/ci.yml
name: ci
on:
  pull_request:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: '3.12'
      - name: Install
        run: pip install -r requirements.txt
      - name: Lint
        run: ruff check .
      - name: Test
        run: pytest -q

Exercise

실제로 쓰는 repo 를 열어. 세어봐: main 의 마지막 commit 으로부터 며칠 지났어? 새 PR 에서 CI run 이 얼마나 걸려? (아니면 CI 가 있었다면 얼마나 걸렸을까?) 두 숫자 다 적어. 첫 번째가 크거나 두 번째가 없으면, 아빠한테 CI 는 없는 거야.