github 액션 yml 파일 만들기 (CI/CD 파이프라인 구축)

오늘은 배포자동화에 필요한 CI/CD 파이프라인 구축을 위해 어떤 코드를 작성해야하는지 알아볼 예정입니다.

 

github 액션을 이용하면 코드를 push 했을때, PR Template 을 통한 체계적인 Pull Request 작성, CI 테스트, CD 테스트, prettier 적용 테스트 등 다양한 테스트를 진행할 수 있습니다.

 

위와 같은 테스트가 필요한 이유는, 사전에 내가 올릴 코드들을 여러가지 test를 통해 협업 브랜치에 merge 됐을 때, 발생하는 오류가 없는지 사전에 확인해보기 위함입니다. 문제발생 가능성이 있거나, 실제로 문제가 있는 코드는  협업 브랜치에 merge 됐을 시 팀원들에게 많은 사랑...을받을 수 있을 겁니다.

그러지 않도록, 협업에서 주로 사용하는 3가지 테스트를 위한 githun action 설정용 코드를 아래와 같이 남겨드리겠습니다.

 

- CI

- CD (vercel로 우선 배포하고, 연동한 뒤 작성해야합니다. 안그러면 테스트 실패함)

- Prettier 

 

우선 확장자는 .yml 입니다. 위 파일들은 아래 경로에 작성합니다.

- 프로젝트의 루트 디렉토리 아래 /github 이름으로 폴더를 만듭니다.

-  /github 폴더 아래 /workflows 폴더를 만듭니다.

- workflows 폴더 아래 .yml 파일을 작성합니다.

위 사진과 같이 작성해주시면 됩니다.

참고로 Pull Request 템플릿을 위한 파일은 workflows 폴더 바로 아래 작성해주시면 됩니다.

 

저는 Pull Request 템플릿을 아래와 같은 양식으로 사용합니다.

## 📝 작업 내용

- 기능에서 어떤 부분이 구현되었는지 설명해주세요

<br/>

## 📢 PR Point

- 

<br/>

## 이미지 첨부


<br/>

## 🔧 다음 할 일

- 다음 할 일을 적어주세요

<br/>

 

CI 테스트

ci.yml

name: CI (develop)

on:
  push:
    branches: [develop]
  pull_request:
    branches: [develop]

jobs:
  build-test:
    runs-on: ubuntu-latest
    timeout-minutes: 10 # 무한 대기 방지

    steps:
      - uses: actions/checkout@v4

      - uses: pnpm/action-setup@v2
        with:
          version: 8
          run_install: false # install 단계에서 직접 캐시 사용

      # 의존성 캐싱
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'pnpm'

      - name: Install deps
        run: pnpm install

      # 타입체크 + 번들
      - run: pnpm run build

      # ESLint (선택 항목)
      - run: pnpm run lint

 

CD 테스트 및 시크릿 변수 등록(github)

deploy.yml

name: Deploy to Vercel (main)

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    timeout-minutes: 10

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

      - uses: pnpm/action-setup@v2
        with:
          version: 8
          run_install: false

      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'pnpm'

      - name: Install dependencies
        run: pnpm install

      - name: Build
        run: pnpm run build # 또는 tsc -b && vite build

      - name: Deploy to Vercel
        uses: amondnet/vercel-action@v25
        with:
          vercel-token: ${{ secrets.VERCEL_TOKEN }}
          vercel-org-id: ${{ secrets.VERCEL_ORG_ID }}
          vercel-project-id: ${{ secrets.VERCEL_PROJECT_ID }}
          vercel-args: '--prod'

참고로 위 코드는 이미 pnpm run build 를 수행하고 있기 때문에 build.sh 파일이 따로 필요하지 않습니다. 

secret 변수는 vercel 배포시 Generate new token (classic) 메뉴를 선택하여 발급받은 뒤 따로 복사해둡니다. 이후 github 의 Org 레포 settings -> Secrets and Variables -> Actions 에서 secret 변수를 등록합니다. 

 

ghp_~~ 로 시작하는 토큰을 AUTO_ACTIONS 라는 이름으로 저장합니다.

이후 본인 깃허브 계정 이메일을 EMAIL 이라는 이름으로 저장합니다.

 

 

제가 사용하는 deploy.yml 파일의 코드를 보면 사진과 같이 VERCEL_ 로 시작하는 시크릿변수를 등록해야함을 알 수 있습니다. 각각의 토큰들은 어디서 발급받는지 아래 참고하시면 됩니다.

 

vercel 로 배포 및 CI/CD 파이프라인 구축하기(배포 자동화)

vercel 로 배포 및 CI/CD 파이프라인 구축하기(배포 자동화)

위 블로그 글의 5번과정 참고하시면 됩니다.

 

 

Prettier 테스트

prettier.yml

name: Prettier

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

jobs:
  prettier:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Install pnpm
        run: npm install -g pnpm

      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'pnpm'

      - name: Install dependencies
        run: pnpm install

      - name: Run Prettier
        run: pnpm prettier --check

 

위 3개의 파일을 참고하셔서 깃허브 자동화 설정 해주시면 됩니다!

 

중요설정 :

main 브랜치 : 배포 연동용

devleop 브랜치(default 로 설정) : 개발용 중앙 브랜치

feat 브랜치 : 기능 개발용 브랜치이며 이는 develop 브랜치로부터 파생됩니다.

 

1. develop 브랜치에서 feat(기능 개발용) 브랜치를 생성하여 작업합니다.

 

2. git push origin [feat브랜치명] 으로 push 후 PR을 작성합니다. 아래 사진과 같이 CI 테스트 및 프리티어 테스트가 진행됩니다.

 

3. 통과되면 merge 가능 상태가 되며 협업시 브랜치 팀별 룰셋에 따라 코드리뷰 및 approve가 필요할 수 있습니다. 

 

4. 이후 feat브랜치의 코드가 develop 브랜치에 merge 되었다면 로컬에서 git pull origin devleop 으로  최신사항을 가져옵니다.

 

5. main 브랜치로 전환합니다.

 

6. git merge develop 을 하여 develop과 sync를 맞춰줍니다.

 

7. git push origin main 으로 main 브랜치에 push 합니다. 이때 main 브랜치는 배포 연동용이며, 배포자동화 설정이 끝났다면, 배포환경에도 반영이 되며 이때 CI, CD, 프리티어 테스트가 진행됩니다. 

 

추가) 프로젝트에 적용한 브랜치 전략 

참고로 제가 진행한 프로젝트의 브랜치 전략은 아래와 같습니다.

master(main) : 기준이 되는 브랜치로 제품을 배포하는 브랜치

develop : 개발 브랜치로 개발자들이 이 브랜치를 기준으로 각자 작업한 기능들을 Merge

feature : 단위 기능을 개발하는 브랜치로 기능 개발이 완료되면 develop 브랜치에 Merge

 

대략적으로 위와 같은 분기를 두어 진행했으며, gitflow 전략을 간소화 시킨것으로 볼 수 있을 것 같네요.

이를 위해 main, develop 브랜치 에 함부로 직접 push 할수 없도록 github 브랜치 보호 rullset을 잘 설정해두는 것도 꼭 필요합니다.

 

개발 프로세스

1. feat 브랜치 즉, 기능 개발 브랜치에서 기능을 개발한 후 원격에 push 합니다.

2. 원격에서 CI 테스트 진행 후 통과하면 develop 브랜치에 merge 합니다.

3. 로컬환경에서 develop 브랜치로 변경한 후 git pull origin develop 으로 최신사항을 유지해줍니다.

4. main 브랜치로 switch 합니다.

5. git merge develop  으로 develop 브랜치의 내용과 sync 를 맞춰줍니다.

6. git push origin main 으로 main브랜치를 push 하면 자동배포가 진행됩니다.