내가 사용하는 GitHub Actions

JeongHoon Park·2022년 4월 5일
11
post-thumbnail

GitHub Actions란?

GitHub Actions는 빌드, 테스트 및 배포 파이프라인을 자동화할 수 있는 CI/CD 플랫폼입니다. 레포지토리에 대한 모든 풀 요청을 빌드 및 테스트하는 워크플로를 생성하거나 병합된 풀 요청을 프로덕션에 배포할 수 있습니다.
GitHub Actions는 단순한 DevOps를 넘어 리포지토리에서 다른 이벤트가 발생할 때 워크플로를 실행할 수 있도록 합니다. 예를 들어, 누군가가 저장소에 새 문제를 생성할 때마다 적절한 레이블을 자동으로 추가하는 워크플로를 실행할 수 있습니다.
-GitHub 홈페이지-

깃헙에서는 GitHub Actions를 위와 같이 설명하고 있다. 쉽게 얘기하면 깃헙에서 특정 이벤트가 발생했을 때 어떤 동작을 할지 설정해놔서 리액션을 자동화하는 서비스라고 생각하면 편할 것이다. 우리가 사용할 리소스를 순수 개발에 더 신경쓸 수 있게된다.


GitHub Actions 적용

나는 주로 3가지의 설정을 많이 사용한다. 3가지 모두 Pull request를 날렸을 때의 액션이 일어난다. 린트 확인, 빌드 테스트, 배포이다. 이 세가지를 사용하여 CI/CD를 자동화하여 사용한다. GitHub Actions 파일들은 .github/workflows 폴더에서 관리해주면된다.

린트 확인

우선 전체 코드를 보여주고 한줄씩 설명하도록 하겠습니다.

name: Lint check 

on: pull_request

jobs:
  build-test:
    name: Next Lint test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-node@v2
        with:
          node-version: '16'
      - run: npm i -g yarn
      - run: yarn
      - run: yarn lint
  • 우선 첫 줄의 name은 위크플로우의 이름이다. 위 값은 다른 워크플로우와 겹치지 않게 사용해야한다.

  • on에서는 레포지토리의 어떤 이벤트를 감지할 것인지 설정해야한다. 위에서는 pull_request를 사용했지만 push를 사용하거나 특정 브랜치, 태그, path에서 작동하도록 설정이 가능하다.

  • 그 다음은 jobs에 관련된 설정이다. name에서 job의 이름을 설정해주고 runs-on에서 어떤 환경에서 사용할지 설정이 가능하다. steps에서는 이제 어떤 일을 해줄지에 대해서 설정을 할 수 있다. Github 마켓플레이스에 올라온 액션의 사용도 가능하고 shell script 실행도 가능하다. 누군가 만들어 놓은 액션을 사용할 때는 uses를 사용해야한다. 그리고 with를 사용하여 액션에 값을 전달할 수도있다. 위의 코드는 node-version이 16이라는 의미다. shell script를 실행할 때는 run 키워드를 사용하면된다. 우리는 npm i -g yarn, yarn, yarn lint 명령어를 실행 시켰다.


빌드 테스트

name: Build test

on: pull_request

jobs:
  build-test:
    name: Next build test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-node@v2
        with:
          node-version: '14'
      - run: npm i -g yarn
      - run: yarn
      - run: yarn build

위의 린트 확인 코드와 거의 동일하며 run에 yarn build 코드만 다르다.


Vercel 배포

GitHub Actions로 Vercel 배포도 자동화가 가능하다. 이 부분도 코드를 먼저 확인한 후 설명을 진행하겠다.

name: Deploy CI
on:
  push:
    branches: [main]
  pull_request:
    types: [opened, synchronize, reopened]
jobs:
  deploy:
    runs-on: ubuntu-latest
    if: "!contains(github.event.head_commit.message, '[skip ci]')"
    steps:
      - name: Checkout
        uses: actions/checkout@v2
      - name: Deploy to Vercel Action
        uses: BetaHuhn/deploy-to-vercel-action@latest
        with:
          GITHUB_TOKEN: ${{ secrets.PERSONAL_ACCESS_TOKEN }}
          VERCEL_TOKEN: ${{ secrets.VERCEL_TOKEN }}
          VERCEL_ORG_ID: ${{ secrets.VERCEL_ORG_ID }}
          VERCEL_PROJECT_ID: ${{ secrets.VERCEL_PROJECT_ID }}

Vercel 배포는 다른 액션들과는 다르게 push 옵션에 브랜치가 설정이 되어있다. main 브랜치에 푸시할 때만 진행된다. pull_request에서는 타입 설정이 되어있다. pull_request가 위의 세가지 타입일 때만 해당 액션이 진행될 것이다.

jobs에 if 키워드를 사용하여 커밑 메시지에 skip ci가 포함되면 액션이 진행되지 않도록 설정되어 있다.

steps의 다른 키워드들은 이전에 봤지만 with 내부의 값들이 처음 보는 방식으로 값이 전달되고 있다. 위의 secret들이 어떻게 설정할 수 있고 위 값들은 어디서 가져와서 쓰는 것인지도 추가로 설명하겠다.

GitHub Secrets

Secrets의 설정은 간단하다. 원하는 레포지토리의 Settings>Secrets>Actions로 들어가면 된다. 들어가면 우측 상단의 New repository secret 버튼을 눌러서 설정하면 된다.

GITHUB_TOKEN

GitHub Token은 레포지토리가 아닌 오른쪽 위 프로필에서 Settings로 들어가야 발급이 가능하다.

  • Settings>Developer settings>Personal access tokens에서 생성이 가능하다. 깃헙에 로그인이 되어있다면 이 링크로 접근이 가능할 것이다.

  • 알맞은 페이지에 들어갔다면 우측 상단의 Generate new token 버튼을 눌러서 토큰을 생성하면된다. 토큰은 workflow 옵션 하나만 설정해주면 된다.

  • 모든 설정 후 토큰을 만들면 토큰 값을 복사할 수 있게 나올 것이다. 해당 값을 복사하여 위의 GitHub Secrets에 들어가서 새 Secret을 만들면 된다.

VERCEL_TOKEN

이제는 Vercel token을 받으러 Vercel로 이동하여야한다.

  • Vercel의 우측 상단의 프로필의 Settings>Tokens로 가면된다. 이것도 마찬가지로 Vercel에 로그인이 되어있다면 이 링크로 접근가능하다.
  • 해당 페이지의 Tokens 섹션에서 Create 버튼을 눌러 토큰을 생성하고 SCOPE는 Full Account를 설정해주면 된다.

마찬가지로 생성된 토큰의 값을 GitHub Secrets에 Secret으로 저장하면 된다.

VERCEL_ORG_ID & VERCEL_PROJECT_ID

이 두개는 한번에 받아올 수 있다. 이 두개는 vercel CLI를 사용해서 받아올 수 있다.

  • 우선 vercel을 깔아야한다.
npm i -g vercel
  • 이후 Vercel에 로그인을 진행해준다.
vercel login
  • 로그인이 다 되었다면 배포를 진행한다.
vercel


위의 과정이 끝나면 .vercel 폴더가 생긴다. 해당 폴더의 project.json파일을 보면 orgId, projectId가 있다. 이 값도 GitHub Secrets에 Secret으로 저장하면 모든 설정은 끝난다.


마무리

위의 세가지를 풀 리퀘스트에서 자동화해주면 배포 시에 생길 문제를 자동으로 체크가 가능해지고 문제가 없다면 배포까지 자동화가 진행된다.
개발을 하다보면 자동화에 대해서 항상 생각하게된다. 개발하는 것 이외에 리소스를 사용하는 것이 너무 아깝기 때문이다. 혹시 저와 같은 생각을 하고 있다면 이 기회에 GitHub Actions를 사용하시는 것을 추천합니다. 그리고 오늘 소개해드린 세가지 말고도 GitHub에서 확인해보면 정말로 많은 workflow가 만들어져있으니 한번 보셨으면 좋겠습니다.

profile
Develop myself, FE developer!

0개의 댓글