GitHub Actions로 구축하는 실전 CI/CD 파이프라인 가이드

 

 

---

개요

최근 CI/CD 도구로 GitHub Actions를 활용한 프로젝트가 점점 늘어나는 추세입니다. 이 문서는 그 이유를 살펴보고, 현재 많이 사용되는 다른 CI/CD 도구와의 장단점을 비교합니다.

이 후, 현재 환경에 GitHub Actions가 적합한 사례가 있다면 워크플로우에 적용해보고자 합니다.

 

CI/CD Popelines

• CI (Continuous Integration) : 지속적인 통합
• CD (Continuous Deployment) : 지속적인 배포

Code -> Build -> Test → Package -> Deploy (Release) -> Operate -> Monitor

 

반응형

 

CI/CD 도구 트렌트

Stack Overflow Trends (언급량 기반 트렌드 분석)

 

 

GitHub Actions란?

GitHub Actions는 GitHub에서 제공하는 빌드, 테스트 및 배포 파이프라인을 자동화할 수 있는 CI/CD(연속 통합 및 지속적인 업데이트) 플랫폼입니다.
GitHub 저장소 내 .github/workflows 폴더에 YAML 형식의 설정 파일로 관리합니다.

YAML

YAML'은 'YAML은 마크업 언어가 아니다(YAML Ain't Markup Language)' 또는 '또 다른 마크업 언어(Yet Another Markup Language)'의 약어입니다.
전통적인 마크업 언어가 아니라 데이터 직렬화에 초점을 맞춘 형식으로 들여쓰기, 키-값 쌍, 배열 표현 등 간결하고 직관적인 문법을 사용하는 마크업언어입니다.

과일:
 - 사과
 - 오렌지
 - 배

 

 

GitHub Actions의 인기 상승 배경

• GitHub와의 자연스러운 통합
  GitHub Actions는 GitHub 내장 기능으로 별도 서버 없이 바로 개발 워크플로를 자동화 등을 사용자가 지정 및 실행할 수 있습니다.

 

• 비용과 유지보수 효율성
  자체 서버를 운영할 필요가 없어 초기 비용과 운영 부담이 적습니다.
• 간편한 설정과 확장성
  YAML 파일 기반의 설정으로 관리가 쉬우며, CI/CD를 포함하여 원하는 작업을 수행하기 위한 작업을 검색, 생성 및 공유하고 완전히 사용자 정의된 워크플로에서 작업을 결합할 수 있습니다.

 

GitHub Actions vs Jenkins 비교

	Jenkins	GitHub Actions
Popelines
설치 및 관리	별도 서버가 필요 파이프라인별 쉘 핸들러 제공	GitHub 내장하여 별도 인프라 불필요 워크플로우 자동화 및 협업 간소화에 사용
커스터마이징	파이프라인별 강력한 플러그인 생태계 다양	제한적이지만 빠른 업데이트와 마켓플레이스 활용
비용	서버 운영비 및 유지보수 비용	무료/유료 플랜 활용
커뮤니티	오픈소스로 탄생 가장 오래된 CI/CD 도구	빠르게 성장 중

 

 

 

GitHub Actions 핵심 개념

1. 워크플로우 (Workflow)

하나 이상의 작업을 실행할 구성 가능한 자동화된 프로세스입니다.

워크플로는 리포지토리의 .github/workflows 디렉터리에 체크된 YAML 파일에서 정의되며 이벤트로 트리거될 때 실행되거나 수동으로 작업을 진행하는 집합입니다.

 

2.잡 (Job)

1. 러너 에서 실행되는 워크플로우의 여러 단계 집합입니다. 각 단계는 실행될 셸 스크립트이거나 실행될 동작 입니다.
2. 각 단계는 순서대로 실행되며 서로 종속됩니다. 각 단계는 동일한 러너에서 실행되므로 한 단계의 데이터를 다른 단계와 공유할 수 있습니다.
3. 작업과 다른 작업의 종속성을 설정할 수 있습니다. 기본적으로 작업은 종속성이 없으며 병렬로 실행됩니다.

3. 액션 (Action)

1. 복잡하지만 자주 반복되는 작업을 수행하는 GitHub Actions 플랫폼용 맞춤형 애플리케이션입니다.
2. 직접 작업을 작성할 수도 있고, GitHub Marketplace에서 워크플로에 사용할 작업을 찾을 수도 있습니다.

4. 이벤트 (Event)

1. 저장소에서 워크플로 실행을 트리거하는 특정 활동입니다.
2. 풀 리퀘스트를 생성하거나, 이슈를 열거나, 저장소에 커밋을 푸시등

<select class="form-select width-full" id="e561165b-8624-4d32-87af-0bddfd00eb96" name="event" value="check_run" data-autosubmit="">
  <option value="">Default</option>
  <option value="branch_protection_rule">branch_protection_rule</option>
  <option selected="selected" value="check_run">check_run</option>
  <option value="check_suite">check_suite</option>
  <option value="create">create</option>
  <option value="delete">delete</option>
  <option value="discussion">discussion</option>
  <option value="discussion_comment">discussion_comment</option>
  <option value="deployment_status">deployment_status</option>
  <option value="deployment">deployment</option>
  <option value="fork">fork</option>
  <option value="gollum">gollum</option>
  <option value="issue_comment">issue_comment</option>
  <option value="issues">issues</option>
  <option value="label">label</option>
  <option value="merge_group">merge_group</option>
  <option value="milestone">milestone</option>
  <option value="page_build">page_build</option>
  <option value="project_card">project_card</option>
  <option value="project_column">project_column</option>
  <option value="project">project</option>
  <option value="public">public</option>
  <option value="pull_request_review_comment">pull_request_review_comment</option>
  <option value="pull_request_review">pull_request_review</option>
  <option value="pull_request">pull_request</option>
  <option value="push">push</option>
  <option value="registry_package">registry_package</option>
  <option value="release">release</option>
  <option value="repository_dispatch">repository_dispatch</option>
  <option value="status">status</option>
  <option value="watch">watch</option>
  <option value="workflow_dispatch">workflow_dispatch</option>
  <option value="workflow_run">workflow_run</option>
  <option value="schedule">schedule</option>
  <option value="pull_request_target">pull_request_target</option>
</select>

 

5. 러너 (Runner)

1. 워크플로가 트리거될 때 이를 실행하는 서버입니다.
2. GitHub에서 호스팅하는 자체 VM 이미지 세트를 관리합니다. 여기에는 macOS, x64 Linux 및 Windows 이미지가 포함됩니다.
3. GitHub에서 호스팅하는 러너를 사용하면 머신 유지 관리 및 업그레이드가 자동으로 처리됩니다.
4. 이미지 목록과 포함된 도구는 actions/runner-images저장소에서 관리됩니다.

 

728x90

 

활용하기 좋은 GitHub Actions 사례

1) PR 머지 기준으로 Storybook의 Chromatic 자동 배포

특정 브랜치(예: main 또는 develop)에 PR이 merge되면 자동으로 Storybook을 Chromatic에 배포하는 워크플로우

 

2) 서브모듈 변경 감지 → 다른 레포지토리에 PR 자동 생성

Git submodule 형태로 관리되는 레포를 사용 중일 때, 서브모듈의 특정 폴더나 파일이 변경되면, 이를 감지하여 다른 레포지토리에 자동 PR을 생성하는 워크플로우.

 

 

자동화를 구축시 고려사항

● 빌드 시간 및 리소스 제한

GitHub Actions는 무료 요금제/기본 제공 요금제에서 빌드 시간 제한, 동시 실행 제한, 런너 리소스 제한(CPU/RAM) 등이 있음.

무거운 빌드나 병렬 작업이 많으면 제한에 걸릴 수 있음.

 

● 복잡한 파이프라인 구성 시 제약

GitHub Actions는 단순한 파이프라인은 쉽게 구성되지만,

너무 복잡한 파이프라인(멀티 프로젝트, 캐싱 전략 복잡, matrix 조합 많음 등)은 관리 난이도가 높아지고 유지보수가 어려워짐.

 

● 보안 설정 및 비밀 관리 방법 중요

Actions에서는 secrets를 통해 토큰/비밀값을 관리하는데, 이를 잘못 설정하면 외부 PR에서 유출될 수도 있어서 주의 필요.

워크플로우가 서드파티 액션을 다운로드할 때도 MITM, 무결성 문제가 있을 수 있음(sha256 pinning 등 필요)

 

 

GitHub Actions 구축하기

1) 테스트 워크플로우 구성하기

1. 저장소 내 .github/workflows/ 폴더를 생성합니다. 모든 워크플로우 파일은 반드시 이 안에 위치해야합니다.
2. workflow에 목적에 따라 YAML 파일을 추가합니다. 예, ci.yml, test.yml
3. workflow 구성 요소에 맞춰 내용을 작성합니다. run의 스크립트는 package.json 파일에 정의가 되어 있어야 합니다.

name: Lint Workflow          # 워크플로우 이름

on:                        # 워크플로우 실행 조건
  push:                    # push 이벤트 발생 시
    branches: [main]
  pull_request:            # PR 생성 또는 변경 시
    branches: [main]

jobs:
  link:                   # job 이름
    runs-on: ubuntu-latest # 실행 환경
    
    steps:                 # job 내 실행 단계
      - name: Checkout source code
        uses: actions/checkout@v4

      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '18'

      - name: Install dependencies
        run: npm install

      - name: Run tests
        run: npm run lint

 

4. 커밋 후 푸시하면 GitHub Actions가 자동으로 실행되며 결과는 GitHub 저장소 내 Actions 탭에서 확인할 수 있습니다.

 

2) Stotybook 자동 배포 워크플로우 구성하기

노드 스크립트 설정

"scripts": {
    "start": "echo \"Server Start\"",
    "env": "cross-env echo \"token=$PROJECT_TOKEN\""
  },

 

Github actions 환경 변수 설정

• 'Settings > environments' New environment 클릭

• Configure DevProject > Environment secrets’ 에서 Add environment secret 선택 후 ‘Add secret’ 등록

• .github\workflows\ 디렉토리에 merge.yml YML 파일 추가 후 원하는 워크플로우 작성

+ 해당 레포지토리가 fork된 경우, .yml 파일 내에서 환경 변수(environment)가 존재하지 않는다는 경고가 표시될 수 있습니다.
실제 workflow 실행에는 문제가 없지만, 이 오류를 해결하려면 fork된 레포지토리에도 동일한 환경 변수를 등록해야 합니다.

# This workflow will do a clean installation of node dependencies, cache/restore them, build the source code and run tests across different versions of node
# For more information see: https://docs.github.com/en/actions/automating-builds-and-tests/building-and-testing-nodejs

name: Node.js CI

on:
  push:
    branches: ["main", "dev"] # PR이 merge되어 main/dev에 반영될 때
  workflow_dispatch:

jobs:
  deploy-on-merge:
    if: github.repository == 'selim0915/frontend-study'
    runs-on: ubuntu-latest
    environment: DevProject # Environment configure name

    strategy:
      matrix:
        node-version: [18.19.0]

    steps:
    - name: Checkout Code
      uses: actions/checkout@v4

    - name: Setup Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v4
      with:
        node-version: ${{ matrix.node-version }}
        cache: 'npm'

    - name: Install dependencies
      run: npm ci

    - name: Deploy with secret
      run: npm run env
      env:
        PROJECT_TOKEN: ${{ secrets.PROJECT_TOKEN }}

 

이벤트 트리거시 GitHub의 Actions 탭에서 workflows 진행 결과 확인

 

Action으로 작성한 명령어의 실행 여부는 로그를 통해 확인합니다. merge.yml 는 콘솔 출력용으로 작성한 명령어이므로, 로그를 조회하여 확인합니다.

 

VS Code용 GitHub Actions 플러그인

VS Code에서 GitHub Actions 확장 기능을 활용하면 워크플로 관리가 훨씬 편해집니다. 주요 기능은 다음과 같습니다.

• 워크플로 및 실행 관리
• 워크플로 편집 (구문 강조, 자동 완성, 호버링 및 유효성 검사)
• CI 빌드 및 배포를 추적
• 실패를 조사하고 로그를 확인
• 환경, 비밀, 변수와 같은 설정 수정

작업을 조금 더 편리하게 관리하고 싶다면 꼭 활용해보세요!