main 브랜치에 직접 병합하며 vercel에 자동으로 배포되었습니다. 그러나 개발 팀 인원이 늘어나고 팀원 간 협업 및 안정성을 위해 GitHub Actions를 활용한 배포 과정을 도입하게 되었습니다.
이전의 문제점
- 안정성 부족 - 직접 Main Branch에 병합하여 배포하면, 개발 중인 기능들이 완전히 테스트되지 않은 상태일 수 있습니다. 이로 인해 예상치 못한 문제가 실제 환경에 영향을 줄 수 있습니다.
- 개발 과정 혼란 -개발 중인 기능들이 Main Branch에 반영되면서, 개발과 배포 사이의 경계가 모호해지고 개발자들 사이에 혼란을 야기할 수 있습니다.
Git-Flow 전략을 접근하여 구성하였습니다.
- Main Branch - Product의 안정적으로 버전이 유지되는 브랜치(배포가 가능한 상태)
- Develop Branch - 개발 브랜치로, 새로운 기능, 버그 수정이 개발되는 브랜치
- Release Branch - 특정 기간 동안 개발된 기능 및 버그 수정된 내용을 출시하기 전에 릴리즈를 준비하는 브랜치, 병합하기 전에 QA 및 테스트를 진행.
배포 과정
- Develop Branch 기준으로 특정 기간동안 개발 및 버그 수정.
- 개발 완료 후 배포주기에 따라 Release Branch 생성
- CI/CD 검증 - Release Branch에서 Main Branch에 병합되기 전에 Github Action을 통해 코드의 품질과 안정성을 검증 및 QA 테스트 진행
- 검증 완료 - 완료 후 Release Branch의 변경 사항을 Main Branch에 병합. Merge commit을 생성하여 명확하게 기록.
- GitHub Releases 생성 - Main Branch에 Release Branch가 병합되면 GitHub Releases를 통해 새로운 릴리스를 만듭니다. 이 단계에서는 릴리스 노트와 함께 새로운 버전을 관리합니다.
- 자동 배포 - 새로운 릴리즈가 만들어지면 Github Action를 통해 Vercel CLI를 사용하여 제품에 배포합니다.
변경된 배포 과정의 이점
- CI/CD 검증을 통하여 변경사항이 Main Branch에 안전하게 병합되는지 확인하여 안정성을 보장.
- 품질관리 Release Branch를 통해 테스트 및 QA를 하여 코드 품질 유지
- Gihub Release를 사용하여 릴리즈를 명확하게 관리하고 노트를 작성하여 사용자들에게 변경사항을 알리는 데 도움이된다.
GitHub Action 적용
GitHub Actions는 build, test 및 배포 파이프 라인을 자동화할 수 있는 CI/CD 플랫폼입니다.
CI 구성
name: CI # 워크플로우의 이름
on:
push: # 푸시 이벤트를 트리거로 설정합니다.
branches: [ main ] # main 브랜치로의 푸시 이벤트를 대상으로 합니다.
pull_request: # 풀 리퀘스트 이벤트를 트리거로 설정합니다.
branches: # 다음 브랜치로의 풀 리퀘스트 이벤트를 대상으로 합니다.
- main # main 브랜치
- deploy/* # deploy/* 패턴을 가진 브랜치들
workflow_dispatch: # 수동으로 실행할 수 있는 워크플로우 디스패치를 허용합니다.
jobs:
ci:
name: Jest Test # 작업의 이름을 Jest Test로 지정합니다.
runs-on: ubuntu-latest # Ubuntu 환경에서 실행합니다.
steps: # 작업에서 실행할 단계들을 정의합니다.
- name: GitHub checkout # 단계의 이름을 지정합니다.
uses: actions/checkout@v4 # GitHub 리포지토리를 체크아웃하는 액션을 사용합니다.
- name: Setup Node.js environment # 단계의 이름을 지정합니다.
uses: actions/setup-node@v4 # Node.js 환경을 설정하는 액션을 사용합니다.
with: # 액션에 전달되는 매개변수를 지정합니다.
node-version: 18 # Node.js 버전을 18로 지정합니다.
cache: yarn # Yarn 패키지 매니저를 캐시합니다.
- name: Cache dependencies # 단계의 이름을 지정합니다.
id: cache # 단계의 ID를 지정합니다.
uses: actions/cache@v4 # 의존성 캐시를 저장하고 복원하는 액션을 사용합니다.
with: # 액션에 전달되는 매개변수를 지정합니다.
path: | # 여러 파일 또는 디렉토리를 지정합니다.
.yarn/cache # Yarn 캐시 디렉토리
key: ${{ github.repository }}-yarn-${{ hashFiles('**/*.lock') }} # 캐시 키를 지정합니다.
restore-keys: | # 복원 키를 지정합니다.
${{ github.repository }}-yarn- # 캐시를 복원할 때 사용됩니다.
- name: Install dependencies # 단계의 이름을 지정합니다.
run: yarn install # Yarn을 사용하여 의존성을 설치합니다.
- name: Unit Test # 단계의 이름을 지정합니다.
run: yarn test:coverage # Jest를 사용하여 유닛 테스트를 실행합니다.
- name: Run Cypress tests # 단계의 이름을 지정합니다.
run: yarn test:e2e # Cypress를 사용하여 엔드 투 엔드(e2e) 테스트를 실행합니다.
GitHub Secrets 설정
원하는 레포지토리의 Settings>Secrets and variables로 들어간다, 들어가면 우측의 New repository secret 버튼을 눌러서 설정하면 된다.
Can you deploy based on tags/releases on Vercel?
How to Deploy Based on Tags or Releases on Vercel
Learn how to use tags and releases to deploy to Vercel, as well as best practices when deploying using these methods.
vercel.com
Vercel Token 생성 >> https://vercel.com/account/tokens
VERCEL_ORG_ID & VERCEL_PROJECT_ID 받기
npm i -g vercel
vercel login
vercelVERCEL_ORG_ID & VERCEL_PROJECT_ID 받기
CD 구성
name: Vercel Production Deployment
env:
VERCEL_ORG_ID: ${{ secrets.VERCEL_ORG_ID }}
VERCEL_PROJECT_ID: ${{ secrets.VERCEL_PROJECT_ID }}
on:
release:
types:
- released
jobs:
Deploy-Production:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Install Vercel CLI
run: npm install --global vercel@latest
- name: Pull Vercel Environment Information
run: vercel pull --yes --environment=production --token=${{ secrets.VERCEL_TOKEN }}
- name: Build Project Artifacts
run: vercel build --prod --token=${{ secrets.VERCEL_TOKEN }}
- name: Deploy Project Artifacts to Vercel
run: vercel deploy --prebuilt --prod --token=${{ secrets.VERCEL_TOKEN }}