Github Actions로 CI/CD 구축 - CI

최훈오·2024년 12월 16일

핏메이트

목록 보기

4/5

그동안 아리까리 했던 CI/CD의 개념을 정리하고 Github Actions를 이용해서 CI/CD를 구축해보기로 했다. 사실 자동 배포와 관련된 워크플로 파일은 작성되어있지만 하나하나 뜯어보지는 않았어서 이를 뜯어보고 CI단계를 추가하려고 한다.

CI/CD란?

CI(Continuous Integration)

개발자가 코드를 공유 저장소에 자주 통합하는 프로세스를 말하며 지속적 통합을 의미한다.
이 과정에서, 빌드와 테스트가 실행되어, 코드 변경이 기존 코드에 미치는 영향을 빠르게 확인할 수 있다.
CI는 코드 변경이 발생할때마다 자동으로 테스트를 수행하여 빌드 실패와 버그를 조기에 발견해 문제를 빠르게 해결하고 개발팀의 효율성을 높이는데 기여한다.

CD(Continuous Delivery)

CI 후에 코드가 프로덕션 환경에 자동으로 배포될 수 있도록 준비하는 프로세스로 지속적 배포를 의미한다.
CD는 CI를 통해 테스트가 완료된 코드를 즉시 프로덕션에 반영해 오래 걸리던 배포 주기를 단축하고 새로운 기능을 더 빠르게 제공한다.

도구

Jenkins, GitLab, Github Actions, AWS 등 다양한 도구가 존재하지만 현재 CD를 Github Actions로 구축해놔서 일관성있게 CI도 Github Actions로 진행했다.

Github Actions에서의 CI

사실 CI가 작성되어있지는 않지만 husky와 lint-staged를 통해 lint룰이 어긋나면 커밋전 오류를 발생시키고, prettier룰이 어긋나면 자동으로 수정되도록 처리를 하고 있다.
하지만, 빌드, 스토리북 빌드, 테스트 등과 관련해서는 어떤 처리도 하고 있지 않아 매번 Merge하고 오류를 발견해서 다시 PR을 작성해 해결한적이 한두번이 아니었다.

따라서, 정리하자면 다음과 같은 이유로 CI를 구축하려고 한다.

PR을 올릴때마다 매번 담당자(Assignees)와 리뷰어(Reviewers)를 등록해줘야 하는 번거로움
커밋시 빌드가 안되면 오류가 나타나지 않음. 심지어 Merge시에도 이를 처리하지 않아 그대로 main 또는 develop 브랜치에 올라가게 됨. -> 배포에 오류가 있는 코드가 그대로 올라가 심각한 문제 발생..

CI

auto-assign

간편하게 이와 관련한 깃헙앱이 존재한다.

사용방법은 엄청 쉽다.
Install -> 원하는 레포지토리 선택 -> 어떤 레포지토리에 적용할건지 선택(사진에는 없지만)하면 끝이다.

이제 워크플로를 작성하면 된다.
크게 두가지로 나뉜다.
1. 규칙을 정의하는 파일(rule)
2. 규칙을 가지고 실제로 실행하는 파일(workflow)

# rule

addReviewers: true # 자동 리뷰어 설정

addAssignees: author # 담당자는 자신 설정

reviewers: # 리뷰어 목록
  - Whoknow77
  - staccato20

numberOfReviewers: 1 # 할당되는 리뷰어 수

skipKeywords: # 룰을 무시하는 키워드(PR 제목이나 본문에 포함된 경우) 
  - exclude

# workflow

name: "Auto Assign" # 워크플로 이름

on: # 워크플로가 트리거되는 이벤트
  pull_request:
    types: [opened, ready_for_review] # PR이 열리거나 리뷰 준비 상태로 전환될때 실행(이외에도 여러 옵션 존재)

jobs: # 워크플로의 작업
  add-reviews:
    runs-on: ubuntu-latest # 환경
    permissions: # 권한
      contents: read 
      pull-requests: write
    steps: # 작업 단계
      - uses: kentaro-m/auto-assign-action@v2.0.0
        with:
          configuration-path: ".github/auto_assign.yml" # 규칙경로

결과

PR을 올리면..

다음과 같이 리뷰어와 담당자가 자동으로 할당된다.

리뷰어에 나도 포함시켜야해서 리뷰어로 나도 할당되는건가? 싶었는데 다행히 알아서 나는 빼고 할당해준다.

빌드, 테스트

이제 매번 PR을 올리고 커밋마다 빌드, 테스트 등을 자동으로 수행하게 해보자.
크게 필요한 처리들은 다음과 같다.

린트
빌드
스토리북 빌드

핏메이트는 테스트코드를 작성하지 않았지만 작성했다면 추가하면 된다.

설정은 다음과 같이 했, 자세한 설명은 코드 안에 주석으로 작성했다.

name: frontend-ci

on:
  pull_request:
    types: [opened, reopened, synchronize] # pr이 열릴때, 다시 열릴때, 다른 코드랑 병합되었을때 발동
    branches: ["main"] # main 브랜치에 PR날릴때 발동

jobs:
  test:
    runs-on: ubuntu-latest
    permissions:
      contents: write # action runner에게 커밋 생성, push 권한 부여
    steps:
      - name: Checkout # 현재 커밋된 코드 다운로드(기본적으로 가장 최신 커밋만 가져오지만, 전체를 가져올 수도 있음)
        uses: actions/checkout@v3

      - name: Setup Node.js # 실행환경에 node.js 설치
        uses: actions/setup-node@v3
        with:
          node-version: 20.9.0

      - name: Install dependencies # 의존성 설치
        run: npm i

      - name: Run lint # 린트
        run: npm run lint

      - name: Run build # 빌드
        run: npm run build

      - name: Run storybook # 스토리북 빌드
        run: npm run build-storybook

결과

일부러 타입 오류, 린트 오류를 내고 actions을 돌려봤다.

각각 잘 잡는 모습이다. 추가적으로 husky로만 cache가 적용된 lint 검증을 하다보니 전체코드에 대해서는 lint룰을 돌려보지 않았었는데 숨어있는 오류를 발견할 수 있었다.

깔끔하게 모두 통과한 모습..

너무 편안하다!

개선점

의존성 설치시 걸리는 시간을 캐싱을 이용해 단축

현재 빌드타임이 1분 내외정도인데 대규모 서비스를 운영하다보면 코드양도 많아져 자연스레 빌드 타임은 이보다 훨씬 늘어날 것이다. 지금은 매번 의존성을 npm i로 새로 설치하지만 캐싱을 활용해서 필요한 부분만 설치한다면 시간을 단축할 수 있다.
병렬처리를 통해 시간 단축

기본적으로 yml의 jobs 내부에 여러 실행들을 작성하면 동기적으로, 순차적으로 작동한다. 만약 병렬적으로 처리될 수 있는 실행들이라면 그렇게 처리하는 것이 더 낫고 역시나 시간을 단축할 수 있다.