CI/CD 구축하기(1) - Github Action 이란?

1. GitHub Action 이란?

Github Action이란 Github 저장소를 기반으로 소프트웨어 개발 Workflow를 자동화 할 수 있는 도구이다.
Github 내부에서 프로젝트를 빌드, 테스트, 릴리즈 또는 배포를 지원하는 기능으로서, Github에서 제공하는 CI/CD 도구라고 생각하면 된다.

 

 

여기를 클릭하면 GitHub Action 공식 문서로 이동할 수 있다. 

 

2. GitHub Action 4가지 주요 개념

Github Action에는 4가지 주요 개념이 존재한다. 이들의 관계와 흐름을 이해해야만 각종 조건과 그에 따른 액션을 스스로 정의할 수 있다.

 

2.1 Workflow

• Workflow는 프로젝트를 빌드, 테스트, 패키지, 릴리스 또는 배포하기 위한 전체적인 프로세스이다.
• Workflow는 여러개의 Job으로 구성되어 event기반으로 동작한다.
• 여러 Job으로 구성되며 최상위 개념이다.
• 나만의 동작을 정의한 Workflow file을 만들어 전달하면 Github Actiond이 실행한다.
• Workflow 파일은 YAML으로 작성되고, Github Repository의 .github/workflows 폴더 아래에 저장됨

 

2.2 Event

• Workflow를 Trigger(실행)하는 특정 활동이나 규칙
• 예를 들어 다음과 같은 상황을 사용할 수 있다.
  • 특정 브랜치로 Push
  • 특정 브랜치로 Pull Request
  • 특정 시간대에 반복(Cron)
  • Webhook을 사용해 외부 이벤트를 통해 실행

 

2.3 Job

• Job은 여러 Step으로 구성되고, 가상 환경의 인스턴스에서 실행된다.
• 다른 Job에 의존 관계를 가질 수 있고, 독립적으로 병렬 실행도 가능하다.

 

2.4 Step

• Step은 순차적으로 명령어를 수행한다.
• Task들의 집합으로, 커맨드를 날리거나 action을 실행할 수 있다.

 

2.5 Action

• Workflow의 가장 작은 블럭
• Job을 만들기 위해 Step들을 연결할 수 있다.
• 재사용이 가능한 컴포넌트
• 개인적으로 만든 Action을 사용할 수도 있고, Marketplace에 있는 공용 Action을 사용할 수도 있음
  • Github Marketplace와 Github Actions Repository에서 확인 가능하다.

 

2.6 Runner

• Gitbub Action Runner 어플리케이션이 설치된 머신으로, Workflow가 실행될 인스턴스
• Github에서 호스팅해주는 Github-hosted runner와 직접 호스팅하는 Self-hosted runner로 나뉨
• Github-hosted runner는 Azure의 Standard_DS2_v2로 vCPU 2, 메모리 7GB, 임시 스토리지 14GB

 

3. CI Workflow 적용

Github Repository 에서 Actions를 클릭한다.

gradle을 이용해서 workflows를 생성하겠다. 템플릿을 만들어 둔 workflow를 활용하면 좀 더 쉽게 작성할 수 있다.

workflow를 작성 후 Start commit 버튼을 클릭한다.

 

다음은 Master 브랜치에 Push 또는 Pull Request가 올 경우 실행되는 CI란 이름을 갖는 Workflow yml 파일 예시이다. 

name: Java CI with Gradle

on:
  push:
    branches: [ master ]
  pull_request:
    branches: [ master ]

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2
    - name: Set up JDK 11
      uses: actions/setup-java@v2
      with:
        java-version: '11'
        distribution: 'adopt'
        
    - name: Grant execute permission for gradlew
      run: chmod +x gradlew
      
    - name: Build with Gradle
      run: ./gradlew build

 

on 부분은 이벤트를 정의하는 부분이다. master branch로 push 또는 pull request가 일어날 경우 해당 workflow가 실행된다.

 on:
    push:
      branches: [ master ]
    pull_request:
      branches: [ master ]

 

jobs 부분을 살펴보자.

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2
    - name: Set up JDK 11
      uses: actions/setup-java@v2
      with:
        java-version: '11'
        distribution: 'adopt'
        
    - name: Grant execute permission for gradlew
      run: chmod +x gradlew
      
    - name: Build with Gradle
      run: ./gradlew build

• Workflow는 여러개의 Job으로 구성된다.
• 여러 Job이 있을 경우, Default로 병렬 실행한다.
• 위의 파일은 build라는 job을 생성하고, 그 아래에 3개의 step이 존재하는 구조이다.
• runs-on은 어떤 OS에서 실행될지 지정한다.
• steps의 uses는 어떤 액션을 사용할지 지정함. 이미 만들어진 액션을 사용할 때 지정한다.

 

jobs 밑에 CI, CD, CI-CD를 넣어서 각각의 역할에 맞게 step을 지정하면 된다.

- name: Build with Gradle
  run: ./gradlew build

 

이 부분에서 build는 build와 test가 합쳐친 부분이다.
만일 test에서 에러나는지, build에서 에러나는지를 따로 확인하고 싶다면 다음과 같이 쓰면 된다.

- name: run test
  run: ./gradlew test

- name: run build
  run: ./gradlew clean build -x test

순서대로 한다면 먼저 단위 테스트를 돌리고, 그 다음 test를 건너뛰로 빌드하는 작업이다.
나누기 귀찮다면 그냥 합쳐서 build로 해도 상관 없다.