메인 기술 탐색 안티스트레스
🇬🇧 English 🇪🇸 Español 🇩🇪 Deutsch 🇫🇷 Français 🇵🇱 Polski 🇨🇿 Česky 🇨🇳 中文 🇰🇷 한국어
홈으로 돌아가기

GitHub Actions로 CI/CD 파이프라인 설정하는 방법 – 가이드

이 포괄적인 가이드는 GitHub Actions로 CI/CD 파이프라인을 설정하는 방법을 설명하며, 기본 워크플로우부터 고급 Docker 배포까지 모든 것을 다룹니다. 실용적인 YAML 예제, 작업 종속성, 캐싱 전략 및 안전한 비밀 관리로 테스트, 빌드 및 배포를 자동화하는 방법을 배우게 됩니다.

By Sudonull Editorial Team • Published • Updated

GitHub Actions를 사용한 CI/CD 파이프라인: 완벽한 설정
Advertisement 728x90

GitHub Actions를 활용한 CI/CD 파이프라인: 완벽 설정 가이드

GitHub Actions를 활용한 CI/CD 파이프라인: 완벽 설정 가이드

현대 소프트웨어 개발에서 코드 변경 시마다 수동으로 테스트하고 배포 스크립트를 실행하는 방식은 전달 속도를 늦추고 사람의 실수를 유발하는 병목 현상을 초래합니다. CI/CD 파이프라인은 코드 테스트부터 프로덕션 배포까지 전체 프로세스를 자동화합니다. 이 가이드에서는 강력하고 통합된 자동화 플랫폼인 GitHub Actions를 사용하여 CI/CD 파이프라인을 설정하는 방법을 실용적이고 실제 업무에 적용 가능한 YAML 예제와 함께 알려드리므로, 더 빠르고 안정적으로 코드를 배포할 수 있습니다.

학습 목표

이 가이드를 마치면 지속적 통합(CI)과 지속적 배포(CD)의 핵심 개념을 이해하고 GitHub Actions를 사용한 다단계 파이프라인을 구현할 수 있게 됩니다. Python, Node.js 또는 컨테이너화된 애플리케이션 등 자신의 프로젝트를 테스트, 빌드, 배포하는 실제 작동하는 YAML 코드를 얻을 수 있습니다.

Google AdInline article slot

GitHub Actions 기본 이해하기

GitHub Actions는 GitHub 저장소에 직접 통합된 이벤트 기반 자동화 플랫폼입니다. push, pull_request, release와 같은 이벤트에 의해 트리거되는 자동화된 워크플로우를 실행할 수 있습니다. 핵심적으로 워크플로우는 .github/workflows/ 디렉토리에 있는 YAML 파일로 정의되며, 기본적으로 병렬로 실행되는 하나 이상의 작업(job)으로 구성되며, 각 작업은 일련의 단계(step)를 포함합니다.

핵심 구성 요소

  • 이벤트 (on): 특정 브랜치로의 push 또는 pull_request와 같이 워크플로우를 시작하는 트리거입니다.
  • 러너 (runs-on): 작업이 실행되는 머신입니다. ubuntu-latest는 성능과 광범위한 소프트웨어 가용성 측면에서 가장 일반적이고 권장되는 선택입니다.
  • 단계 (Steps): 작업 내의 개별 작업입니다. 셸 스크립트(run) 또는 GitHub Marketplace의 사전 빌드된 액션(uses)이 될 수 있습니다.
  • 액션 (Actions): 저장소를 복제하는 actions/checkout@v4 또는 Node.js를 설치하는 actions/setup-node@v4와 같은 재사용 가능한 코드 단위입니다.

시작하기 위한 기본 워크플로우

가장 간단한 워크플로우는 모든 푸시에 대해 트리거될 수 있습니다. .github/workflows/main.yml 파일을 생성하여 기본 "Hello World" 명령을 실행합니다.

name: example
on: push
jobs:
  greeting:
    runs-on: ubuntu-latest
    steps:
      - run: echo "Hello, CI/CD World!"

이 파일을 저장소에 커밋하고 푸시한 후, GitHub 저장소의 "Actions" 탭에서 작업의 출력을 확인할 수 있습니다.

Google AdInline article slot

포괄적인 CI 파이프라인 구축

파이프라인의 "CI" 부분은 코드 변경 사항이 병합되기 전에 자동으로 테스트되고 검증되도록 보장합니다. 여기에는 일반적으로 린팅, 타입 검사 및 단위 테스트 실행이 포함됩니다.

CI 워크플로우 파일

.github/workflows/ci.yml을 생성합니다. 이 워크플로우는 main 브랜치에 대한 모든 push 및 pull_request에서 트리거됩니다. 아래 예제는 Node.js 프로젝트에 대한 완전한 파이프라인을 보여주지만, 이 패턴은 actions/setup-python을 사용하는 Python과 같은 다른 언어에도 적용됩니다.

name: CI Pipeline

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm run lint

  test:
    runs-on: ubuntu-latest
    needs: lint
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm test

  build:
    runs-on: ubuntu-latest
    needs: [lint, test]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm run build

주요 기능 설명

  1. 의존성 캐싱: actions/setup-node의 cache: 'npm' 옵션은 이전 실행의 의존성을 재사용하여 워크플로우 속도를 크게 높입니다.
  2. 작업 의존성: needs 키워드는 실행 순서를 정의합니다. 예를 들어, build 작업은 lint 및 test 작업이 성공한 경우에만 실행됩니다. 이는 손상된 코드를 빌드하는 데 시간을 낭비하는 것을 방지합니다.
  3. 환경 변수: 데이터베이스와 같은 서비스의 경우 환경 변수를 정의할 수 있습니다. 예를 들어, test 작업은 PostgreSQL 서비스 컨테이너를 실행하고 env를 사용하여 연결할 수 있습니다.

고급 시나리오: 컨테이너화 및 다중 환경 배포

최신 애플리케이션의 경우 파이프라인에는 종종 컨테이너 이미지 빌드 및 배포가 포함됩니다. 다음 표는 일반적인 배포 전략과 해당 트리거를 간략하게 설명합니다.

Google AdInline article slot

배포 트리거 비교

전략 배포 트리거 최적 사용 사례
브랜치 기반 main 브랜치로 push 최신 개발 코드의 지속적 배포
태그 기반 새 태그 푸시 (예: v1.0.0) 안정적이고 버전 관리된 소프트웨어를 프로덕션에 릴리스
릴리스 기반 GitHub에 release 게시 릴리스 노트도 생성하는 공식 제품 릴리스

예제: CI/CD 워크플로우로 Docker 컨테이너 배포

이 포괄적인 예제는 Python 애플리케이션을 테스트하고, Docker 이미지를 빌드하고, 레지스트리로 푸시하는 파이프라인을 보여줍니다. 안전하고 고성능 빌드를 위해 일련의 공식 Docker 액션을 사용합니다.

.github/workflows/deploy.yml 생성:

name: Complete CI/CD Pipeline

on:
  push:
    branches: [ main ]
  release:
    types: [published]

env:
  DOCKER_HUB_USERNAME: ${{ secrets.DOCKER_HUB_USERNAME }}
  DOCKER_HUB_TOKEN: ${{ secrets.DOCKER_HUB_TOKEN }}
  IMAGE_NAME: my-app

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v4
        with:
          python-version: '3.9'
      - run: pip install -r requirements.txt
      - run: pytest

  build-and-push:
    runs-on: ubuntu-latest
    needs: test
    if: github.event_name == 'push' || github.event_name == 'release'
    steps:
      - uses: actions/checkout@v4
      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v3
      - name: Login to Docker Hub
        uses: docker/login-action@v3
        with:
          username: ${{ env.DOCKER_HUB_USERNAME }}
          password: ${{ env.DOCKER_HUB_TOKEN }}
      - name: Extract metadata
        id: meta
        uses: docker/metadata-action@v5
        with:
          images: ${{ env.DOCKER_HUB_USERNAME }}/${{ env.IMAGE_NAME }}
          tags: |
            type=ref,event=branch
            type=semver,pattern={{version}}
            type=raw,value=latest,enable={{is_default_branch}}
      - name: Build and push
        uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          tags: ${{ steps.meta.outputs.tags }}
          labels: ${{ steps.meta.outputs.labels }}
          cache-from: type=gha
          cache-to: type=gha,mode=max

  deploy:
    runs-on: ubuntu-latest
    needs: build-and-push
    if: github.event_name == 'release'
    steps:
      - name: Execute Deployment Script
        run: |
          echo "Deploying image ${{ env.DOCKER_HUB_USERNAME }}/${{ env.IMAGE_NAME }}:${{ github.event.release.tag_name }}"

중요: 시크릿 관리

위 워크플로우가 작동하려면 GitHub 저장소에 자격 증명을 안전하게 저장해야 합니다. Settings > Secrets and variables > Actions로 이동하여 다음 시크릿을 추가합니다.

  1. DOCKER_HUB_USERNAME: Docker Hub 사용자 이름.
  2. DOCKER_HUB_TOKEN: 읽기/쓰기 권한이 있는 Docker Hub 개인 액세스 토큰.

⚠️ 보안 경고: 비밀번호, 토큰 또는 기타 민감한 데이터를 YAML 파일에 직접 하드코딩하지 마십시오. 항상 암호화되어 워크플로우 실행 중에만 액세스할 수 있는 GitHub 시크릿을 사용하세요.

자주 묻는 질문

GitHub Actions로 CI/CD 파이프라인을 설정하는 첫 번째 단계는 무엇인가요?

시작하려면 저장소에 .github/workflows 디렉토리를 만드세요. 내부에 YAML 파일(예: ci.yml)을 만들고 name, on(예: push와 같은 트리거 이벤트) 및 jobs(실행할 작업)를 정의합니다. 이 파일을 커밋하고 푸시하면 첫 번째 자동화된 워크플로우가 시작됩니다.

GitHub Actions를 사용하여 풀 리퀘스트에서 테스트를 실행할 수 있나요?

네, 풀 리퀘스트 테스트는 핵심 사용 사례입니다. main 브랜치에 대한 on 트리거를 pull_request로 설정하면 워크플로우가 모든 새 풀 리퀘스트에서 자동으로 실행되어 병합 전에 코드 품질을 보장합니다.

GitHub Actions 워크플로우로 Docker 이미지를 빌드하고 푸시하려면 어떻게 해야 하나요?

docker/login-action, docker/setup-buildx-action 및 docker/build-push-action과 같은 공식 복합 액션을 사용할 수 있습니다. 이는 프로세스를 단순화하고, 인증을 자동으로 처리하며, 빌드 캐싱 및 다중 플랫폼 빌드와 같은 기능을 활성화합니다.

GitHub Actions를 사용하여 GitHub Pages에 배포할 수 있나요?

네. JamesIves/github-pages-deploy-action 커뮤니티 액션을 사용할 수 있습니다. 빌드된 사이트가 포함된 폴더로 구성하면 gh-pages 브랜치에 변경 사항을 커밋하고 푸시하는 git 작업을 처리합니다.

push 이벤트 트리거와 release 이벤트 트리거의 차이점은 무엇인가요?

push 이벤트는 코드가 지정된 브랜치로 푸시될 때마다 워크플로우를 트리거합니다. release 이벤트는 GitHub 릴리스가 게시될 때 트리거됩니다. push는 일반적으로 CI 및 스테이징 배포에 사용되는 반면, release는 프로덕션에 배포하는 데 자주 사용됩니다.

출처

— Editorial Team

Advertisement 728x90

다음 읽기

태그

#github-actions #ci-cd-pipeline #devops-automation #docker-deployment

주제

DevOps CI/CD

FAQ

GitHub Actions로 CI/CD 파이프라인을 설정하기 위한 첫 번째 단계는 무엇인가요?

저장소에 .github/workflows 디렉토리를 만들고, 이름, 트리거 이벤트(예: push) 및 작업을 정의하는 YAML 파일을 추가하세요. 커밋하고 푸시하면 첫 번째 자동 실행이 시작됩니다.

GitHub Actions를 사용하여 풀 리퀘스트에서 테스트를 실행할 수 있나요?

네, 'on' 트리거를 메인 브랜치의 'pull_request'로 설정하세요. 워크플로우는 새로운 PR이 있을 때마다 자동으로 실행되어 병합 전에 코드 품질을 확인합니다.

GitHub Actions 워크플로우로 Docker 이미지를 빌드하고 푸시하려면 어떻게 하나요?

공식 Docker 액션을 사용하세요: 인증을 위한 docker/login-action, Buildx 설정을 위한 docker/setup-buildx-action, 그리고 캐싱 및 멀티 플랫폼 지원으로 빌드 및 푸시를 위한 docker/build-push-action.

GitHub Actions를 사용하여 GitHub Pages에 배포할 수 있나요?

네, JamesIves/github-pages-deploy-action 커뮤니티 액션을 사용할 수 있습니다. 빌드된 사이트가 포함된 폴더로 구성하여 gh-pages 브랜치에 변경 사항을 커밋하고 푸시합니다.

푸시와 릴리스 이벤트 트리거의 차이점은 무엇인가요?

푸시 이벤트는 지정된 브랜치에 코드 푸시 시 트리거되며, CI 및 스테이징에 적합합니다. 릴리스 이벤트는 GitHub 릴리스가 게시될 때 트리거되며, 일반적으로 프로덕션 배포에 사용됩니다.