GitHub Actions는 뭘까?

GitHub Actions는 빌드, 테스트 및 배포 파이프라인을 자동화할 수 있는 CI/CD(연속 통합 및 지속적인 업데이트) 플랫폼입니다. 리포지토리에 대한 모든 끌어오기 요청을 빌드 및 테스트하거나 병합된 끌어오기 요청을 프로덕션에 배포하는 워크플로를 만들 수 있습니다.

처음 접하면 말이 약간 어렵게 느껴질 수도 있을 것 같다.

간단히 말하자면
깃헙에서 제공하는 VM을 사용하여
PR을 올리거나, 특정 브랜치에 커밋이 푸쉬되었을 때
특정 작업들을 자동화 할 수 있는 것이다.

언제 무엇을 할 수 있는걸까?

예를 들면, 아래의 경우를 자동화 할 수 있다.

1. PR이 생성되거나 업데이트되면 테스트 실행해서 테스트 코드가 통과하는지 확인한다.
2. PR이 생성되거나 업데이트되면 린터를 실행해서 어긋나는 스타일이 없는지 확인한다.
3. PR이 생성되거나 업데이트되면 빌드가 깨지지 않는지 확인한다.
4. 특정 브랜치에 커밋이 푸쉬되었을 때, 서버에 자동적으로 배포되게 할 수 있다. (예를 들면 develop, main 브랜치에 PR이 머지되었을 때, 자동으로 배포)

또한 GitHub의 브랜치 보호 규칙을 설정하면, 해당 작업들이 통과할 경우에만 PR을 머지할 수 있도록 설정할 수 있어 협업 시 안전성을 높일 수 있다.

깃헙 액션을 활용할 수 있는 방법은 무궁무진하다.

어떻게 사용할 수 있을까?

이렇게 편리한 기능을 어떻게 사용할 수 있는걸까?

우선 .github/workflows 디렉토리 하위에 .yaml/.yml 파일을 작성해야 한다.

여러 개의 파일을 만들어서 종류별로 구분을 둘 수도 있고,
하나의 파일에 여러 개의 작업을 묶어서 작성할 수도 있다.

예를 들면

1. test.yml
2. lint.yml
3. build.yml
4. deploy.yml

이런 식으로 파일을 나눌 수도 있고, 작업들을 하나의 파일에 여러 개의 job으로 묶을 수도 있다.

사실 깃헙 액션은 공식문서 설명이 너무 잘 되어 있다...!

그 중에서 Node.js 빌드 및 테스트 예제를 가지고 왔다.

# 참고: YAML 파일은 파이썬과 유사하게 들여쓰기로 데이터의 계층 관계를 표현한다.
# 들여쓰기 수준에 따라 데이터의 종속성 또는 그룹이 결정된다.

name: Node.js CI
# GitHub Actions에서 워크플로 이름
# 어떤 작업인지 설명하는 이름을 작성하는 것이 좋다.

on: [push]
# on: 트리거를 정의하는 부분
# 어떤 이벤트에서 이 워크플로가 실행될지 정의한다.
# 푸시(push) 이벤트가 발생하면 워크플로가 실행됨을 의미한다.

# on:
#	push:
#    	branches: ['develop']
#	pull_request:
#   	branches: ['develop']
# 위 코드는 'develop' 브랜치로의 푸시 또는 PR 이벤트가 발생할 때 워크플로가 실행되도록 설정하는 예시이다.

jobs: 
  test:  # 첫 번째 작업 이름
    runs-on: ubuntu-latest 
    # 해당 작업에서 실행할 가상 머신의 OS를 지정한다.
    # GitHub에서는 Ubuntu, macOS, Windows VM을 제공하지만, 대부분의 경우 Ubuntu를 사용한다.

    strategy:
      matrix:
        node-version: ['18.x', '20.x']
        # matrix 전략을 사용하면 여러 환경에서 작업을 병렬로 실행할 수 있다.
        # 여기서는 Node.js의 18.x와 20.x 버전 두 가지 환경에서 작업을 실행한다.

    steps: 
    # 각 작업의 단계를 정의한다. 
    # 단계는 순차적으로 실행되며, "-"로 각 단계를 나열한다.
      - uses: actions/checkout@v4 
      # GitHub Actions의 기본 체크아웃 액션을 사용한다.
      # 이는 CI 서버에서 리포지토리 코드를 가져오는 역할을 한다.
      # 기본적으로 현재 푸시된 브랜치의 코드를 체크아웃한다.
      
      - name: Use Node.js 
      # 단계의 이름을 지정한다.
      # 실행 로그에서 이 단계를 식별하는 데 사용된다.
        uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
          # matrix에서 정의한 Node.js 버전(18.x, 20.x)을 사용한다.
          # 명시적으로 버전을 설정할 수도 있다 (예: '20.x').

      - run: npm ci
      # npm의 ci 명령어를 실행하여 의존성을 설치한다.
      # npm ci는 package-lock.json에 명시된 정확한 버전으로 패키지를 설치하므로 CI 환경에 적합하다.
      # name: Install dependencies 와 같은 이름을 붙일 수 있다.
      # npm 대신 yarn을 사용할 수도 있다.

      - run: npm test
      # 테스트를 실행하는 npm 명령어를 실행한다.
      # npm test는 프로젝트의 모든 테스트를 실행하는 역할을 한다.
      
  build: # 두 번째 작업 이름
    runs-on: ubuntu-latest 
    # 두 번째 작업에서 사용할 VM의 OS

    strategy:
      matrix:
        node-version: ['18.x', '20.x']
        # 여러 Node.js 버전에서 병렬로 실행

    steps: 
    # 빌드 작업을 정의하는 단계
      - uses: actions/checkout@v4 
      # 체크아웃 액션 사용 (코드 가져오기)

      - name: Use Node.js 
        uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
          # node-version을 matrix에서 가져옴

      - run: npm ci
      # 의존성 설치

      - run: npm run build --if-present
      # 빌드를 실행하는 npm 명령어를 실행한다.
      # --if-present 플래그는 build 스크립트가 존재하지 않는 경우에도 에러를 발생시키지 않고 무시한다.
      

jobs를 여러 개로 분리하는 이유는 뭘까?

1. 병렬 처리로 속도 향상
   test와 build 작업을 별도의 job으로 정의하면, 서로 의존하지 않는 작업들이 동시에 실행될 수 있다. 이렇게 하면 전체 파이프라인의 실행 시간을 단축할 수 있다.

2. 작업 간의 분리로 가독성 및 유지보수성 향상
   각 job을 목적별로 분리하면 워크플로의 가독성이 높아지고, 나중에 수정하거나 유지보수할 때도 훨씬 수월하다.

3. 실패한 job만 재시도 가능
   빌드가 성공하고 테스트가 실패했다면, 빌드를 다시 실행하지 않고 테스트만 재시도할 수 있다.

4. 조건부 실행 및 의존성 관리
   각 job은 서로 독립적이지만, 의존성을 설정할 수 있다. 예를 들어, test job이 성공해야만 build job을 실행하도록 설정할 수도 있다.
   이를 통해 중요한 작업이 성공한 후에만 다른 작업을 실행하는 구조를 만들 수 있어, 불필요한 실행을 방지할 수 있다.

5. 각 작업에 다른 환경 설정 가능
   runs-on 옵션을 사용하면 각 job에서 다른 운영체제 또는 다른 설정을 사용하여 실행할 수 있다. 예를 들어, 하나의 job은 ubuntu에서, 다른 job은 windows에서 실행되도록 할 수 있다.

6. 분리된 로그 및 결과 관리
   각 job마다 독립된 로그가 생성되므로, 어떤 job에서 오류가 발생했는지 쉽게 확인할 수 있다. 이로 인해 디버깅이 훨씬 쉬워지고, 문제 해결에 도움이 된다.

아주 간단한 깃헙 액션 설정을 살펴봤다.
배포 자동화가 궁금하다면 Amazon ECS배포를 참고하면 좋을 것 같다!