GitHub Actions의 소개와 핵심 개념

GitHub가 Microsoft에 인수된 이후 야심차게 출시한 GitHub Actions는 CI/CD 시장에 지각변동을 일으키고 있는데요. 전 세계에 대부분의 개발자들이 이미 깃허브 계정이 있다고 해도 과언이 아닌 유리한 상황에서, GitHub Actions의 약진은 Jenkins, Circle CI, Travis CI와 같은 기존에 유수의 서비스까지도 위협하고 있습니다.

이번 포스팅은 제 블로그에서 GitHub Actions에 대해서 처음 다루는 만큼 GitHub Actions를 처음 접하시는 분들을 위해서 아주 얇고 넓게 GitHub Actions에 대한 핵심 개념 위주로만 알아보려고 합니다.

GitHub Actions란?

GitHub Actions는 코드 저장소(repository)로 유명한 깃허브(GitHub)에서 제공하는 CI(Continuous Integration, 지속 통합)와 CD(Continuous Deployment, 지속 배포)를 위한 비교적 최근에 추가된 서비스입니다. 당연히 GitHub에서 코드를 관리하고 있는 소프트웨어 프로젝트에서 사용할 수 있으며 개인은 누구나 GitHub에서 코드 저장소를 무료로 만들 수 있기 때문에 다른 CI/CD 서비스 대비 진입장벽이 낮은 편입니다.

GitHub Actions를 사용하면 자동으로 코드 저장소에서 어떤 이벤트(event)가 발생했을 때 특정 작업이 일어나게 하거나 주기적으로 어떤 작업들을 반복해서 실행시킬 수도 있습니다. 예를 들어, 누군가가 코드 저장소에 Pull Request를 생성하게 되면 GitHub Actions를 통해 해당 코드 변경분에 문제가 없는지 각종 검사를 진행할 수 있고요. 어떤 새로운 코드가 기본 브랜치(master 또는 main)에 유입(push)되면 GitHub Actions를 통해 소프트웨어를 빌드(build)하고 상용 서버에 배포(deploy)할 수도 있습니다. 뿐만 아니라 매일 밤 특정 시각에 그날 하루에 대한 통계 데이터를 수집시킬 수도 있습니다.

이렇게 소프트웨어 프로젝트에서 지속적으로 수행해야하는 반복 작업들을 업계에서는 소위 CI/CD라고 많이 줄여서 부르는데요. 사람이 매번 직접 하기에는 비효율적인데다가 실수할 위험도 있기 때문에 자동화시키는 것이 유리합니다.

GitHub Actions는 기존 CI/CD 서비스 대비 간편한 설정과 높은 접근성으로 특히 개발자들 사이에서 많은 호응을 얻고 있는데요. 예전에는 CI/CD가 DevOps 엔지니어의 전유물로만 여겨지곤 했었는데 최근에는 GitHub Actions을 통해서 일반 개발자들도 스스로 CI/CD 설정을 스스로 하는 것을 어렵지 않게 볼 수 있습니다.

자, 그럼 지금부터 GitHub Actions를 사용하기 전에 숙지하고 있으면 큰 도움이 되는 몇 가지 핵심 개념을 살펴보도록 하겠습니다.

Workflows

GitHub Actions에서 가장 상위 개념인 워크플로우(Workflow, 작업 흐름)는 쉽게 말해 자동화해놓은 작업 과정이라고 볼 수 있습니다. 워크플로우는 코드 저장소 내에서 .github/workflows 폴더 아래에 위치한 YAML 파일로 설정하며, 하나의 코드 저장소에는 여러 개의 워크플로우, 즉 여러 개의 YAML 파일을 생성할 수 있습니다.

이 워크플로우 YAML 파일에는 크게 2가지를 정의해야하는데요. 첫번째는 on 속성을 통해서 해당 워크플로우가 언제 실행되는지를 정의합니다.

예를 들어, 코드 저장소의 main 브랜치에 push 이벤트가 발생할 때 마다 워크플로우를 실행하려면 다음과 같이 설정해줍니다.

on:  push:    branches: [main]
jobs:
  # ...(생략)...

다른 예로, 매일 자정에 워크플로우를 실행하려면 다음과 같이 설정합니다.

on:  schedule:    - cron: "0 0 * * *"
jobs:
  # ...(생략)...

두번째는 jobs 속성을 통해서 해당 워크플로우가 구체적으로 어떤 일을 해야하는지 명시해야하는데요. 이 부분은 내용이 많으니 다음 섹션에서 알아볼까요?

Jobs

GitHub Actions에서 작업(Job)이란 독립된 가상 머신(machine) 또는 컨테이너(container)에서 돌아가는 하나의 처리 단위를 의미합니다. 하나의 워크플로우는 여러 개의 작업으로 구성되며 적어도 하나의 작업은 있어야 합니다. (아니라면 실행할 작업이 없으니 워크플로우가 의미가 없겠죠?) 그리고 모든 작업은 기본적으로 동시에 실행되며 필요 시 작업 간에 의존 관계를 설정하여 작업이 실행되는 순서를 제어할 수도 있습니다.

작업은 워크플로우 YAML 파일 내에서 jobs 속성을 사용하며 작업 식별자(ID)와 작업 세부 내용 간의 맵핑(mapping) 형태로 명시가 되는데요.

예를 들어, job1, job2, job3이라는 작업 ID를 가진 3개의 작업을 추가하려면 다음과 같이 설정합니다.

# ...(생략)...

jobs:  job1:    # job1에 대한 세부 내용  job2:    # job2에 대한 세부 내용  job3:    # job3에 대한 세부 내용

작업의 세부 내용으로는 여러 가지 내용을 명시할 수 있는데요. 필수로 들어거야 하는 runs-on 속성을 통해 해당 리눅스나 윈도우즈와 같은 실행 환경을 지정해줘야 합니다.

예를 들어, 가장 널리 사용되는 우분투의 최신 실행 환경에서 해당 작업을 실행하고 싶다면 다음과 같이 설정합니다.

# ...(생략)...

jobs:
  job1:
    runs-on: ubuntu-latest    steps:
      # ...(생략)...

작업에서 가장 중요한 부분은 작업 순서를 정의하는 것일텐데요. 이 부분은 steps 속성을 통해서 설정을 하며 다음 섹션에서 자세히 알아보겠습니다.

Steps

정말 단순한 작업이 아닌 이상 하나의 작업은 일반적으로 여러 단계의 명령을 순차적으로 실행하는 경우가 많죠? 그래서 GitHub Actions에서는 각 작업(job)이 하나 이상의 단계(step)로 모델링이 되는데요.

작업 단계는 단순한 커맨드(command)나 스크립트(script)가 될 수도 있고 다음 섹션에서 자세히 설명할 액션(action)이라고 하는 좀 더 복잡한 명령일 수도 있습니다. 커맨드나 스크립트를 실행할 때는 run 속성을 사용하며, 액션을 사용할 때는 uses 속성을 사용합니다.

예를 들어 자바스크립트 프로젝트에서 테스트를 돌리려면 코드 저장소에 코드를 작업 실행 환경으로 내려 받고, 패키지를 설치한 후, 테스트 스크립트를 실행해야할텐데요. 이 3단계의 작업은 아래와 같이 steps 속성을 통해서 명시될 수 있을 것입니다.

# ...(생략)...

jobs:
  test:
    runs-on: ubuntu-latest
    steps:      - uses: actions/checkout@v3      - run: npm install      - run: npm test

워크플로우 파일 내에서 작업 단계를 명시해줄 때는 주의할 부분이 있는데요. YAML 문법에서 시퀀스(sequence) 타입을 사용하기 때문에 각 단계 앞에 반드시 -를 붙여줘야 합니다.

Actions

마지막으로 살펴볼 개념은 GitHub Actions의 꽃이라고 볼 수 있으며 서비스 이름에도 들어있는 단어인 바로 액션(Action)입니다. 액션은 GitHub Actions에서 빈번하게 필요한 반복 단계를 재사용하기 용이하도록 제공되는 일종의 작업 공유 메커니즘인데요. 이 액션은 하나의 코드 저장소 범위 내에서 여러 워크플로우 간에서 공유를 할 수 있을 뿐만 아니라, 공개 코드 저장소를 통해 액션을 공유하면 GitHub 상의 모든 코드 저장소에서 사용이 가능해집니다.

GitHub에서 제공하는 대표적인 공개 액션으로 바로 위 예제에서도 사용했던 체크 아웃 액션(actions/checkout)을 들 수 있는데요. 대부분의 CI/CD 작업은 코드 저장소로 부터 코드를 작업 실행 환경으로 내려받는 것으로 시작하므로 이 액션이 얼마나 범용적으로 사용될지는 굳이 말씀을 안 드려도 상상이 가시죠?

뿐만 GitHub Marketplace에서는 수많은 벤더(vendor)가 공개해놓은 다양한 액션을 쉽게 접할 수가 있는데요. 한 마디로 이 액션을 중심으로 하나의 큰 커뮤니티가 형성이 되고 더 많은 사용자와 벤더가 GitHub Actions으로 몰려드는 선순환이 일어나고 있습니다.

마치면서

지금까지 GitHub Actions에 대해서 핵심 개념 위주로 간단히 살펴보았습니다.

간단히 배운 개념을 정리해볼까요?

워크플로우(workflow)는 자동화 시켜놓은 작업 과정을 뜻하며 YAML 파일을 통해 어떤 작업(job)들이 언제 실행되야 하는지를 설정합니다.

각 워크플로우는 독립된 환경에서 실행되는 작업(job)이 적어도 한 개 이상으로 구성되며, 각 작업에는 작업 ID가 부여되고 세부 내용(실행 환경, 작업 단계 등)이 명시됩니다.

하나의 작업은 보통 순차적으로 수행되는 여러 개의 단계(step)로 정의되며, 각 단계는 단순한 커맨드(command)일 수도 있고 추상화된 액션(action)일 수도 있습니다.

추후 포스팅에서는 실제로 GitHub Actions을 어떻게 설정하고 활용할 수 있는지에 대해서 알아보도록 하겠습니다.

GitHub Actions 관련 포스팅은 GitHub Actions 태그를 통해서 쉽게 만나보세요!