해당 포스팅은 사이드 프로젝트 진행 중 겪은 크고 작은 이슈들에 대한 기록입니다.

CI/CD 툴 변경

• 기존 인프라 구축 당시, CI 담당 툴로 Travis CI를 선택하였다.

• 허나 한달이 지난 시점에 Trial 기간이 끝나면서 더 이상 사용하지 못 하게 되었다...

  • (1만 크레딧을 다 소모하지 않아도 1달의 기간이 지나면 자동으로 정지됨)

• 위의 이유로 인해, 무료 CI 툴인 Github Actions으로 Migration 하기로 결정하였다.

01. Github Actions이란?

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

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 호출은 별도의 공부가 필요함.)
• 이 장점은 곧, 개발자들이 한 눈에 워크플로우 실행 과정을 파악할 수 있다는 큰 장점으로 작용할 것이다.
  
  

---

참고 블로그

• Github Actions 구축 과정 참고