Continuous Integration이 뭐야

멈추지 않는 통합

Continuous Integration은 모든 변경을 자주, 보통 개발자 한 명당 하루에 여러 번씩 공유 main 브랜치로 병합하고, 병합할 때마다 자동화된 빌드, 테스트, 린트 순서를 돌리는 거야. 핵심 단어는 continuous야. nightly가 아니고, weekly도 아니야. 매 푸시, 매 PR, 매 커밋마다 돌아가야 해.

이 원칙은 도구보다 오래됐어. Grady Booch가 1991년에 이 표현을 처음 만들었지. 아이디어 자체는 더 오래됐어. 병합하지 않은 작업을 쌓아두면 결국 병합 과정이 작은 고고학 프로젝트처럼 변해버려. CI는 비용 구조를 뒤집어서, 매 푸시마다 작은 비용을 내고 릴리스할 때 거대한 비용을 한 번에 내는 일을 막아주는 거야.

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

Checkout — 테스트할 커밋을 정확히 그것만 가져오기.
런타임 세팅 — Python, Node, JDK 등 프로젝트에 필요한 것들을 고정된 버전으로 설치하기.
의존성 설치 — 보통 캐시를 써서 두 번째 실행은 더 빠르게 만들기.
Lint, type-check, format-check — 빠른 정적 검사 통과시키기.
Test — 유닛, 통합, 때로는 엔드투엔드 테스트 돌리기.
Report — 성공이면 초록, 실패면 빨간색으로 표시하고 로그와 아티팩트까지 남기기.

결과물은 커밋당 1비트야: 이 변경을 병합해도 안전함 아니면 이 변경이 깨졌음. 나머지 로그, 아티팩트, 커버리지 리포트는 그 비트를 둘러싼 장식일 뿐이야.

Code

가장 작은 의미 있는 CI 워크플로·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

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

멈추지 않는 통합

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

Code

External links

Exercise

Progress

댓글 0