이 글에서 얻는 것

  • CI/CD 개념: 왜 “자동화"가 선택이 아닌 필수인지 이해합니다.
  • GitHub Actions 구조: Workflow > Job > Step 계층 구조를 파악합니다.
  • 실전 파이프라인: Spring Boot 프로젝트를 PR 날릴 때마다 “빌드 + 테스트” 하는 yaml을 짭니다.

1. CI/CD가 뭔가요?

  • CI (Continuous Integration): “하루에 10번 머지해라.”
    • 개발자 A, B, C가 짠 코드를 매일 합치고, 테스트해서 깨지는지 확인하는 것.
  • CD (Continuous Deployment): “버튼도 누르지 마라.”
    • 테스트 통과하면 자동으로 AWS/Docker 서버까지 배포되는 것.

2. GitHub Actions 구조 (.github/workflows)

GitHub 저장소의 .github/workflows/ 폴더에 yaml 파일만 넣으면 끝입니다.

name: Java CI with Gradle

on: # 1. Trigger
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

jobs: # 2. 할 일 목록 (기본적으로 병렬 실행)
  build:
    runs-on: ubuntu-latest # 3. 실행 환경 (Runner)

    steps: # 4. 세부 단계 (순차 실행)
    - uses: actions/checkout@v3 # 코드 내려받기
    
    - name: Set up JDK 17
      uses: actions/setup-java@v3
      with:
        java-version: '17'
        distribution: 'temurin'
        
    - name: Grant execute permission for gradlew
      run: chmod +x gradlew
      
    - name: Build with Gradle
      run: ./gradlew build # 테스트 포함

3. 핵심 기능: Secrets & Cache

Secrets (보안)

application.yml에 DB 비밀번호를 적어서 커밋하면 해킹당합니다. GitHub Settings -> Secrets에 저장하고, yaml에서 꺼내 씁니다.

env:
  DB_PASSWORD: ${{ secrets.DB_ONLY_PASS }}

Cache (속도)

Gradle 빌드의 절반은 “라이브러리 다운로드"입니다. 캐싱하면 1분 걸리던 게 10초가 됩니다.

- uses: actions/cache@v3
  with:
    path: |
      ~/.gradle/caches
      ~/.gradle/wrapper
    key: ${{ runner.os }}-gradle-${{ hashFiles('**/*.gradle*', '**/gradle-wrapper.properties') }}

4. 실전 워크플로우 전략

  1. PR 검증: pull_request 트리거로 테스트(test)만 돌립니다. 실패하면 Merge 버튼 비활성화.
  2. 배포: main 브랜치에 push 되면, 빌드 후 Docker 이미지를 만들고 AWS로 쏘는(CD) 잡을 실행합니다.

요약

  1. 자동화: 내가 자는 동안에도 테스트는 돌아야 한다.
  2. YAML: .github/workflows에 정의하면 GitHub이 알아서 서버를 빌려주고 실행해준다.
  3. Secrets: 비밀번호는 절대 코드에 넣지 말고 Secrets를 써라.