Git이 기반

파이프라인은 Git 이벤트에 반응해

겉으로는 화려해 보여도 모든 CI/CD 시스템의 본질은 Git 이벤트 수신기야. Push, 태그, 풀 리퀘스트 같은 이벤트가 워크플로를 실행하는 조건이 되거든. Git을 제대로 알면 CI/CD의 절반은 이미 장악한 거야.

GitHub에서 자주 쓰는 이벤트는 이래:

푸시 — 모든 브랜치에 반응하거나 특정 브랜치만 골라서 반응할 수 있어.
pull_request — opened, synchronized(새 커밋 푸시), reopened, ready_for_review 같은 상태 변화에 반응해.
태그 푸시 — 보통 릴리스 파이프라인에 써(v1.2.3 태그를 푸시하면 릴리스 워크플로가 실행돼).
schedule — cron처럼 정해진 시간에 돌아가는 거라 야간 빌드나 의존성 스캔에 딱이야.
workflow_dispatch — UI나 API에서 수동으로 실행하는 조건이야.
repository_dispatch — 외부 시스템이 저장소를 호출할 때 써.

브랜치 전략과 CI 구조

대표적인 브랜치 전략 두 가지는 CI 구조에 완전히 다른 영향을 줘:

Trunk-based — 수명이 짧은 피처 브랜치를 쓰고 매일 병합해. 모든 PR과 main 푸시마다 CI가 돌아가서 매끄럽고 빠르지만, 철저한 규율이 필요해.
Git Flow — develop, 릴리스, hotfix 브랜치를 오래 유지해. 브랜치 종류마다 통과 조건이 달라서 CI가 더 복잡해지고 느려. 의식적인 절차가 많지만 릴리스 주기가 느린 규제 산업이나 패키지 소프트웨어에서는 유용해.

전략부터 정해. CI 구조는 그 뒤를 따라오게 마련이야.

Code

워크플로별 실행 조건·yaml

# .github/workflows/pr.yml — runs on PRs only
name: pr-checks
on:
  pull_request:
    types: [opened, synchronize, reopened]

# .github/workflows/release.yml — runs on tag pushes
name: release
on:
  push:
    tags: ['v*.*.*']

# .github/workflows/nightly.yml — runs at 06:00 UTC daily
name: nightly
on:
  schedule:
    - cron: '0 6 * * *'
  workflow_dispatch: {}

Exercise

저장소에 있는 모든 워크플로 파일을 나열해 봐(없으면 공개 저장소 하나 골라). 각각 어떤 Git 이벤트가 실행 조건인지, 어떤 브랜치나 태그에서 도는지, 어떤 종류의 작업인지(lint? 테스트? 릴리스? schedule?) 적어. 중복도 찾아봐.

파이프라인은 Git 이벤트에 반응해

브랜치 전략과 CI 구조

Code

External links

Exercise

Progress

댓글 0