Github Actions으로 CI/CD 구축하기

이민영·2025년 3월 5일
post-thumbnail

1. CI/CD란❓

CI/CD는 Continuous Integration(지속적인 통합)Continuous Deployment/Delivery(지속적인 배포/제공)의 약자로, 소프트웨어 개발에서 코드 변경을 자동으로 빌드, 테스트, 배포하는 프로세스를 의미한다. 이를 통해 개발자는 더욱 빠르고 안정적으로 제품을 출시할 수 있다.

1.1 ✅ CI(Continuous Integration)

지속적인 통합이라는 의미로, 개발자가 작업한 코드를 주기적으로 빌드하고 테스트한 후, 메인 레포지토리에 병합(merge)하는 과정을 말한다.

🔹 CI의 핵심 목표:

  • 개발자들이 짧은 주기로 코드를 병합함으로써 코드 충돌을 최소화
  • 자동화된 테스트를 통해 버그를 빠르게 감지 및 수정
  • 안정적인 코드 상태 유지
  • 배포 전 코드 품질을 지속적으로 검증

1.2 ✅ CD(Continuous Deploy, Continuous Delivery)란?

CD는 Continuous Deployment(지속적인 배포)와 Continuous Delivery(지속적인 제공) 두 가지 의미를 포함하며, CI 이후의 배포 과정을 자동화하는 단계이다.

🔹 CD의 주요 목적:

  • 코드를 빠르고 안전하게 프로덕션 환경에 배포
  • 배포 과정의 자동화를 통해 수작업 부담 감소
  • 빠른 피드백을 반영하여 사용자 경험 개선

📌 CD의 두 가지 형태

Continuous Delivery(지속적인 제공)
1. CI 이후 자동으로 배포 가능한 상태까지 준비하지만, 실제 배포는 사람이 수동으로 결정
2. 예: QA 팀의 검토 후 프로덕션에 배포

Continuous Deployment(지속적인 배포)
1. 코드가 테스트를 통과하면 자동으로 프로덕션 환경에 배포
2. 빠른 반복과 신속한 기능 제공이 가능하지만, 높은 수준의 자동화가 필요


2. Github Actions란❓

GitHub Actions는 Github에서 제공해주는 CI/CD(연속 통합 및 지속적인 배포)를 자동화할 수 있는 서비스이다. GitHub에서 코드를 관리하고 있는 소프트웨어 프로젝트에서 사용할 수 있으며 개인은 누구나 GitHub에서 코드 저장소를 무료로 만들 수 있기 때문에 다른 CI/CD 서비스 대비 진입장벽이 낮은 편이다.

GitHub Actions는 기존 CI/CD 서비스 대비 간편한 설정과 높은 접근성으로 특히 개발자들 사이에서 많은 호응을 얻고 있다. 예전에는 CI/CD가 DevOps 엔지니어의 전유물로만 여겨지곤 했었는데, GitHub Actions을 통해서 일반 개발자들도 스스로 CI/CD 설정을 어렵지 않게 할 수 있다.

✅ Github Actions을 활용한 CI/CD 전체 흐름

  1. 개발자가 코드를 수정하고 GitHub에 push
  2. GitHub Actions Workflow가 자동으로 실행되어 빌드 및 테스트 진행
  3. 테스트에 통과하면 PR을 병합하거나 자동으로 배포 프로세스 진행
  4. GitHub Actions가 스테이징 또는 프로덕션 환경에 배포
  5. 배포 후 GitHub Actions에서 모니터링 및 오류 감지 (Slack, Discord 알림 연동 가능)

3. Github Actions 핵심 개념

3.1 Workflow, Job, Step, Action 개념

📌 Workflow

  • GitHub Actions에서 가장 상위 개념으로, 자동화된 작업의 전체 흐름을 의미한다.
  • .github/workflows/ 폴더 내의 YAML 파일로 설정하며, 여러 개의 Workflow를 만들 수 있다.
  • 특정 이벤트(push, pull_request, schedule 등)를 트리거로 실행된다.
name: CI/CD Workflow  # Workflow 이름
on: push  # push 이벤트 발생 시 실행
jobs: 
 (생략...)

📌 Job

  • Workflow 내부에서 실행되는 작업 단위
  • 하나의 Workflow는 여러 개의 Job을 포함할 수 있으며, 각 Job은 독립적으로 실행되거나 순차적으로 실행될 수 있다.
  • runs-on을 사용하여 실행 환경(예: ubuntu-latest, windows-latest)을 지정한다.
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Run Build
        run: echo "Building the project..."

위 예제에서 build Job이 실행되며, ubuntu-latest 환경에서 실행된다.

📌 Step

  • Job 내부에서 실행되는 단위 작업
  • 여러 개의 Step이 모여 하나의 Job을 구성한다.
  • uses를 사용하여 미리 정의된 Action을 실행하거나, run을 사용하여 직접 명령어를 실행할 수 있다.
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Repository
        uses: actions/checkout@v3  # 미리 정의된 Action 사용
      - name: Run Tests
        run: npm test  # 직접 실행할 명령어

📌 Action

  • GitHub Actions에서 사용되는 개별 작업 모듈
  • Step에서 uses를 통해 호출하며, 공식 GitHub Actions Marketplace에서 제공하는 Action을 사용할 수도 있고, 직접 생성할 수도 있다.
  • 예: actions/checkout, actions/setup-node
steps:
  - name: Checkout Code
    uses: actions/checkout@v3  # 레포지토리 코드 다운로드
  - name: Setup Node.js
    uses: actions/setup-node@v3
    with:
      node-version: 18  # Node.js 버전 지정
  • actions/checkout@v3 → GitHub 레포지토리의 코드를 가져오는 Action
  • actions/setup-node@v3 → Node.js 환경을 설정하는 Action

3.2 Runner와 실행 환경

📌 Runner란?

  • GitHub Actions의 Workflow를 실행하는 서버 또는 머신
  • GitHub이 제공하는 호스팅 Runner와, 직접 관리하는 Self-hosted Runner 두 가지 방식이 있다.
  • Workflow에서 runs-on을 설정하여 어떤 Runner에서 실행할지 지정할 수 있다.

📌 GitHub 호스팅 Runner

  • GitHub에서 제공하는 머신으로, 자동으로 제공되어 따로 설치할 필요가 없다.
  • 환경에 따라 ubuntu-latest(기본값), windows-latest, macos-latest
    지정할 수 있다.
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    (생략...)

📌 Self-hosted Runner

  • 사용자가 직접 운영하는 머신으로, 직접 설치가 필요하다.
  • 특정 서버에 self-hosted Runner 등록 후 사용이 가능하다.
jobs:
  deploy:
    runs-on: self-hosted  # 직접 운영하는 Runner 사용

4. Github Actions 기본 설정

4.1 .github/workflows 폴더와 YAML 파일

  • GitHub Actions의 Workflow 설정 파일은 .github/workflows/ 폴더에 위치한다.
  • Workflow는 YAML(.yml 또는 .yaml) 파일로 작성되며, 여러 개의 Workflow 파일을 만들 수 있다.

📌 예시: 폴더 구조

📦 프로젝트 루트
 ┣ 📂 .github
 ┃ ┗ 📂 workflows
 ┃   ┣ 📜 ci.yml  # CI 관련 Workflow
 ┃   ┣ 📜 cd.yml  # CD 관련 Workflow
 ┃   ┗ 📜 deploy.yml  # 배포 관련 Workflow

4.2 Workflow 트리거(이벤트)

  • GitHub Actions는 특정 이벤트 발생 시 자동으로 실행되며, 주요 트리거는 다음과 같다.
  • push : 브랜치에 코드가 푸시될 때 실행
  • pull_request : PR이 생성, 업데이트, 병합될 때 실행
  • schedule : 일정 시간마다 자동 실행 (CRON 방식)
  • workflow_dispatch : 수동 실행 (GitHub UI에서 실행 가능)
on:
  push:
    branches:
      - main  # main 브랜치에 푸시될 때 실행
  pull_request:
    branches:
      - main  # main 브랜치로 PR이 생성될 때 실행
  schedule:
    - cron: "0 0 * * *"  # 매일 자정에 실행 (UTC 기준)
  workflow_dispatch:  # 수동 실행
  • push → main 브랜치에 코드가 푸시되면 실행
  • pull_request → main 브랜치에 대한 PR이 생성되면 실행
  • schedule → 매일 자정(UTC 00:00)에 실행
  • workflow_dispatch → GitHub Actions에서 직접 실행 버튼을 눌러 실행

4.3 기본적인 Workflow 예제

name: CI Workflow  # Workflow 이름

on: push  # push 이벤트 발생 시 실행

jobs:
  build:
    runs-on: ubuntu-latest  # 실행 환경 지정

    steps:
      - name: Checkout Repository
        uses: actions/checkout@v3  # 코드 가져오기

      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: 18  # Node.js 18 버전 사용

      - name: Install Dependencies
        run: npm install  # 패키지 설치

      - name: Run Tests
        run: npm test  # 테스트 실행

이렇게 설정하면 코드가 푸시될 때마다 자동으로 빌드 및 테스트가 실행된다! 🚀


5. CI (Continuous Integration) 구축하기

5.1 CI 구축하기

CI(지속적 통합)는 코드가 변경될 때마다 자동으로 빌드, 테스트, 코드 스타일 검사를 수행하여 품질을 유지하는 과정이다.

✅ CI 구축 기본 흐름

  1. 개발자가 코드를 변경하고 push 또는 PR 생성
  2. GitHub Actions가 자동으로 빌드 및 테스트 실행
  3. 테스트 통과 시 코드 병합 가능 (PR에서 확인 가능)
  4. 테스트 실패 시 PR에 오류 표시, 개발자가 수정 후 다시 실행
name: CI Pipeline

on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main

jobs:
  build-test:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout Repository
        uses: actions/checkout@v3

      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: 18

      - name: Install Dependencies
        run: npm install

      - name: Run Linter
        run: npm run lint  # ESLint 실행

      - name: Run Tests
        run: npm test  # Jest 테스트 실행

6. CD (Continuous Deployment) 구축하기

6.1 CD 구축하기

CD(지속적 배포)는 CI 과정이 끝난 후, 테스트를 통과한 코드가 자동으로 배포되는 과정이다.

✅ CD 구축 흐름

  1. 코드 변경 → CI 과정 실행 (빌드 & 테스트)
  2. 테스트 통과 시 자동으로 배포

📌 예제: AWS EC2 + Nginx로 배포

name: CD Pipeline

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout Repository
        uses: actions/checkout@v3

      - name: Install Dependencies
        run: npm install

      - name: Build Project
        run: npm run build

      - name: Deploy to EC2
        uses: appleboy/ssh-action@v0.1.6
        with:
          host: ${{ secrets.EC2_HOST }}
          username: ${{ secrets.EC2_USER }}
          key: ${{ secrets.EC2_PRIVATE_KEY }}
          script: |
            cd /home/ec2-user/app
            git pull origin main
            npm install
            npm run build
            pm2 restart all
  • appleboy/ssh-action을 사용해 EC2에 SSH로 접속 후 배포
  • secrets를 이용해 민감한 정보 보호

6.2 Secrets 설정 및 환경 변수 관리

배포 과정에서 API 키, SSH 키, DB 정보 같은 중요한 정보는 GitHub Secrets에 저장하여 관리한다.

✅ Secrets 설정 방법

  1. GitHub 저장소 → Settings → Secrets → New repository secret

  2. 환경변수 추가

  • EC2_HOST: EC2 서버 주소
  • EC2_USER: EC2 접속 사용자
  • EC2_PRIVATE_KEY: SSH 접속 키

참고로 환경변수의 변수명은 사용자 임의로 지어도 된다.

✅ YAML에서 Secrets 사용 예시

with:
  host: ${{ secrets.EC2_HOST }}
  username: ${{ secrets.EC2_USER }}
  key: ${{ secrets.EC2_PRIVATE_KEY }}

✅ .env 파일을 GitHub Actions에서 사용하는 방법

  1. .env 파일을 저장소에 올리지 않고 GitHub Secrets에 등록
  2. secrets에서 .env 파일을 생성 후 사용
- name: Create .env file
  run: |
    echo "API_KEY=${{ secrets.API_KEY }}" >> .env
    echo "DB_URL=${{ secrets.DB_URL }}" >> .env
  1. 이후 빌드 및 실행 과정에서 .env 사용 가능


출처

https://www.youtube.com/watch?v=0Emq5FypiMM&t=2s
https://docs.github.com/ko/actions/about-github-actions/about-continuous-integration-with-github-actions
https://www.daleseo.com/github-actions-basics/

profile
Frontend Developer

0개의 댓글