Migrating to Github Actions

  • 기존 인프라 구축 당시, CI 담당 툴로 Travis CI를 선택하였다.
  • 허나 한달이 지난 시점에 Trial 기간이 끝나면서 더 이상 사용하지 못 하게 되었다…
    • (1만 크레딧을 다 소모하지 않아도 1달의 기간이 지나면 자동으로 정지됨)
  • 위의 이유로 인해, 무료 CI 툴인 Github Actions으로 Migratino을 하기로 결정하였다.

01. Github Actions이란?

  • Github에서 제공하는 CI(Continuous Integration)와 CD(Continuous Deployment)를 위한 서비스.
  • Github를 사용하던 일반 개발자들 입장에서 다른 CI/CD 서비스에 비하여 좋은 접근성과 직관적이며 간단한 설정으로 인하여 큰 호응을 얻고 있다.
  • Github Actions Document

02. 핵심 개념

Workflows (워크플로우)

  • 가장 최상위 개념으로 자동화시키고자 하는 작업 과정을 명시하는 파일.

  • YAML파일로 설정하며, 프로젝트 내부 .github/workflows 디렉토리 아래에 위치시킴.

  • on 속성과 jobs 속성, 이 두가지 속성으로 워크플로우의 전체 과정을 정의함.

  • 워크플로우 문법

  • 기본적인 YAML 파일 예시 (java - using gradle)

  • name: [ 워크플로우 이름 ]
on:
  push:
    branches: [ 브랜치 이름 ]
  pull_request:
    branches: [ 브랜치 이름 ]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - name: Set up JDK 11
      uses: actions/setup-java@v3
      with:
        java-version: '11'
        distribution: 'temurin'
    - name: Build with Gradle
      uses: gradle/gradle-build-action@67421db6bd0bf253fb4bd25b31ebb98943c375e1
      with:
        arguments: build
  • name: 전체 워크플로우 이름

On

  • 워크플로우의 실행 시점을 설정하는 속성
  • event: 어떤 event가 발생할 때 실행될 것인가를 정하는 속성 (위의 예시에서 push, PR에 해당)
  • event.branches: 이벤트가 발생할 브랜치 이름

Jobs

  • 독립된 가상 머신 또는 컨테이너에서 돌아가는 하나의 처리 단위.
  • 최소 하나의 작업이 있어야 함.
  • name: 추가하고자 하는 작업의 이름을 명시 (위의 예시에서 build에 해당)
    • build라는 옵션이 아니라 name의 값을 build로 정한 것 => 헷갈릴 수 있음
  • name.runs-on: 워크플로우가 실행될 환경을 설정하는 옵션

jobs.name.steps

  • 해당 작업의 명령을 단계 별로 기술하는 옵션
  • name: stpe의 이름을 부여하는 옵션 (생략 가능)
  • uses: Github Actions에서 제공하는 action이라는 명령어를 사용할 때 쓰는 옵션
  • run: 커맨드나 스크립트를 실행할 때 사용하는 옵션 (예시에 없음)

Actions

  • CI/CD 과정은 아무래도 반복되는 단계를 많이 거치게 될 수 밖에 없음.
  • 이를 재사용하기 위해 제공되는 일종의 작업 공유 메커니즘.
  • Actions들을 모아둔 Marketplace 링크

03. Migration 이후 느낀점

  • 처음 Migration을 하기로 마음 먹었을 때는 지레 겁을 많이 먹었다. 하지만 공식 문서를 찬찬히 살펴보고 몇번의 시행착오를 거쳐보니 느낀점은 오히려 Travis CI보다 직관적이고 편하다였다!
  • 기존의 .travis.yml 파일을 대신할 YAML 파일을 .github/workflows 내부에 생성하고 주어진 메뉴얼들을 참고하여 적용해보니 생각보다 수월하게 Migration에 성공하였다.
  • 두 툴을 모두 찍먹(?) 느낌으로 맛만 본 입장에서 느낀 점을 간략하게 정리해보자면 아래와 같다.

1. 가장 큰 장점! 일단 무료다!!!

  • 1인 개발자이거나 나처럼 프로젝트를 준비하는 취준생의 입장에서 비용 절감은 매우 중요한 부분이다.
  • 물론 모든 부분에서 무료인 것은 아니지만, 현재 내가 원하는 수준에서 이 정도로 간편하게 사용할 수 있으면서 가격적 부담감을 느끼지 않게 해주는 것만으로도 너무 완벽한 선택인 것 같다.
  • Github Actions 공식 가격 정책 링크

2. 일단 써봐야 안다.

  • 위에 서술한 것처럼 Migration을 직접 진행하기 전까진 두려웠고 되게 어렵게 느껴졌던 것이 사실이다.
  • 하지만 공식 문서와 여러 좋은 블로그 게시글들을 참고하여 직접 작성해보니 생각보다 쉽게 성공하였다.
  • 물론 현재로써 내 지식 수준은 겉 핥기 레벨이겠지만, 성공을 했다는 그 경험이 있기에 더 깊고 넓은 공부를 할 수 있다는 자신감을 얻었다.

3. Steps 옵션이 정말 직관적이다.

  • jobs의 steps 옵션이 정말 너무 직관적이다.
  • 처음 예시들을 봤을 땐 이해 자체를 하지 못했지만, 알고 보니 steps 옵션이 너무 간결하고 이뻐보였다(?).
  • Travis CI를 사용할 땐, YAML 파일에서 주어지는 옵션들을 하나 하나 파악해가면서 그 값을 일일히 세팅하는 불편함이 있었다면, Github Actions에선 steps 내부에 내가 원하는 로직을 순서에 맞게 기입하고 run 옵션을 통해 원하는 커맨드를 실행시켜주면 끝이다. (물론 uses를 통한 action 호출은 별도의 공부가 필요함.)
  • 이 장점은 곧, 개발자들이 한 눈에 워크플로우 실행 과정을 파악할 수 있다는 큰 장점으로 작용할 것이다.


참고 블로그

댓글남기기

참고