일단 ci를 돌려볼까?

김강민·2024년 12월 17일

목록 보기

15/16

최근에 프로젝트와 해커톤을 진행하면서 있었던 일이다.

"강민님! 제 개발 환경에서는 ESLint 문제가 나타나지 않았는데, 왜 계속 Action이 돌아갈때 build 되면서 eslint test에 걸리는지 모르겠어요.."

S3(cloudFront)로 배포를 하게되면 배포를 담당하는 branch로 merge를 진행해야 배포가 진행된다. 나는 보통 브랜치 운영을 main-develop-feature 과 같은 방식으로 진행하기 때문에 배포 branch를 main branch로 세팅해둔다.

feature -> develop 에서는 각자 작업한 것들을 모아서 운영하고, develop -> main 에서는 모든 오류를 해결한 이후 배포를 진행하는게 간편하다고 생각했기 때문이다.

근데 여기서 feature -> develop 으로 넘어올 때는 몰랐던 eslint 오류나 기타등등의 오류가 develop -> main으로 넘어올 때 발견되면 참 골치가 아프다.

"그럼 새로 Issue를 파서 작업할까요? 근데 매번 Issue를 파서 오류만 Fix하는게 맞나?"
이게 참 의문이었다. 그렇다고 develop -> main 에서 발생한 오류를 모두 hotfix로 수정하기엔 너무 hotfix를 자주 사용하는것 같다. 진짜 급한 오류를 수정한건지, 단순한 코드 포맷팅이나 기타 오류만 수정한건지 알 수가 없을 수도 있을 것 같다는 생각이 들었다.

그래서 배포할때 작성해둔 Git Action 스크립트를 유심히 살펴보았다.

name: S3 deploy

on:
  push:
    branches: ['Weekly']
env:
  AWS_REGION: ap-northeast-2
  S3_BUCKET_NAME: sinitto
permissions:
  contents: read

jobs:
  deploy:
    name: Deploy
    runs-on: ubuntu-latest
    steps:
      - name: Checkout source code.
        uses: actions/checkout@master

      - name: Cache node modules
        uses: actions/cache@v4
        with:
          path: node_modules
          key: ${{ runner.OS }}-build-${{ hashFiles('**/package-lock.json') }}
          restore-keys: |
            ${{ runner.OS }}-build-
            ${{ runner.OS }}-

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

      - name: Create .env file
        run: |
          echo "VITE_APP_BASE_URL=${{ secrets.VITE_APP_BASE_URL }}" >> .env
          echo "VITE_APP_KAKAO_AUTH_CLIENT_ID=${{ secrets.VITE_APP_KAKAO_AUTH_CLIENT_ID }}" >> .env
          echo "VITE_APP_KAKAO_AUTH_REDIRECT_URI=${{ secrets.VITE_APP_KAKAO_AUTH_REDIRECT_URI }}" >> .env
          echo "VITE_ENV"=${{ secrets.VITE_ENV }} >> .env

      - name: Install Dependencies
        run: pnpm install --no-frozen-lockfile --force

      - name: Lint Code
        run: pnpm lint

      - name: Build
        run: pnpm run build

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ${{ env.AWS_REGION }}

      - name: Upload to AWS S3
        run: |
          aws s3 cp \
            --recursive \
            --region ap-northeast-2 \
            ./dist s3://${{env.S3_BUCKET_NAME}}
      - name: Invalidate CloudFront cache
        run: |
          aws cloudfront create-invalidation \
            --distribution-id ${{ secrets.CLOUDFRONT_DISTRIBUTION_ID }} \
            --paths "/*"

한번 쭉 읽어보면서 이런 생각이 들었다.
"S3로 배포하지 말고 package manager만 설치해서 lint test랑 build만 진행하면 되지 않을까?"

Pull Request 단계에서 이 테스트가 진행된다면 그 PR이 열려있는 상태에서 오류를 수정하고 push 하면 바로 반영이 되니까 hotfix라는 커밋 헤더를 사용할 이유가 없겠다는 생각이 들어서 이것저것 찾아보니까 ci/cd 에서 ci만 진행하는 그런 방법이 있다고 한다.

사실 ci/cd가 뭔지 정확히 몰랐는데 ci가 약간 테스트 하는 느낌이고, cd가 배포하는 느낌인가보다~ 라고만 단순하게 생각했다. (진짜 몰랐음)

그래서 아래와 같이 한번 작성해보았다.

name: ESLint & Build Test

on:
  pull_request:
    branches:
      - Master
      - Develop
      - Weekly
  workflow_dispatch:

jobs:
  test:
    runs-on: ubuntu-latest

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

      - name: Install NodeJs & Pnpm package manager
        uses: actions/setup-node@v4
        with:
          node-version: 22

      - name: Install Pnpm package manager
        run: |
          npm install -g pnpm

      - name: Install Dependencies
        run: pnpm install

      - name: Lint Code
        run: pnpm lint
      
      - name: Build Test
        run: pnpm run build

전체적인 흐름은, 원하는 브랜치의 PR이 생성되었을 때 해당 Action을 자동으로 진행한다는 것이다. 그럼 조금 더 자세하게 알아보자.

pull_request:
    branches:
      - Master
      - Develop
      - Weekly

Pull request가 생성되고, 어떤 브랜치를 향하게 될 때 이 test를 진행할건지 브랜치 이름을 작성한다.
예를 들어서, 내가 feature/issue-#100 에서 작업을 진행하고, feature/issue-#1 -> develop 으로 향하는 PR을 생성하면 해당 Action이 자동으로 ESLint test와 Build test 까지 진행해준다.