원큐에 끝내는 GitHub Actions 를 이용한 CI 구축 : 기본 실습 가이드

안녕하세요!

지난 번에는 CI(Continuous Integration) 프로세스와 도구 선택에 대해 알아보았습니다.

2023.11.14 - [해축갤 프로젝트/CI CD] - CI(Continous Integration) 도구 선택 고민 원큐에 끝내기

CI(Continous Integration) 도구 선택 고민 원큐에 끝내기

1. 저장소 설정
2. 빌드 스크립트 작성
3. 테스트 자동화
4. 품질 검사 도구 통합(선택, 추후)
5. 알림 설정
6. 문서화 및 유지보수

오늘은 이 프로세스를 실제로 GitHub Actions를 사용하여 CI를 구축하는 과정을 살펴보겠습니다.

 

1. GitHub 의 Actions 탭 클릭 및 템플릿 선택

먼저 Repository 의 메인 화면으로 이동하여 Actions 탭을 클릭합니다.

레포지토리 메인

아래 있는 여러 사각형들은 CI에 대한 여러 추천 템플릿들입니다.

여러 템플릿 중 'Java with Gradle'을 선택하거나,

상단에 위치한 'Set up a workflow yourself' 를 클릭할 수 있습니다.

 

2. 템플릿 사용 vs 직접 설정

템플릿을 사용하면 기본적인 CI 파이프라인 설정을 자동으로 생성할 수 있습니다.

이는 초보자에게 편리하지만, 프로젝트의 특정 요구사항을 반영하기 위해선 수정이 필요할 수 있습니다.

 

직접 설정할 경우, .github/workflows 디렉터리에 새 YAML 파일을 생성하고

필요한 빌드 및 테스트 명령을 작성해야 합니다.

이 방법은 더 많은 유연성을 제공합니다.

3. YAML 파일 작성

저는 Java with Gradle 템플릿을 선택해 YAML 파일을 작성했습니다.

자동 작성된 yml 파일

Publish Java Package with Gradle와Java with Gradle 둘 다 

선택해도 상관없을 거 같아 보이지만 제 CI의 요구사항은

코드의 매 업로드마다 자동 test & build입니다.

 

그리고 이러한 요구사항에 걸맞은 선택은 Java with Gradle입니다.

두 차이점에 대해서는 다음 글에서 보여드리겠습니다.!

 

Java with Gradle 템플릿을 생성하면 다음과 같이 YAML을 작성해 줍니다.

# This workflow uses actions that are not certified by GitHub.
# They are provided by a third-party and are governed by
# separate terms of service, privacy policy, and support
# documentation.
# This workflow will build a Java project with Gradle and cache/restore any dependencies to improve the workflow execution time
# For more information see: https://docs.github.com/en/actions/automating-builds-and-tests/building-and-testing-java-with-gradle

name: Java CI with Gradle

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

permissions:
  contents: read

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@bd5760595778326ba7f1441bcf7e88b49de61a25 # v2.6.0
      with:
        arguments: build

근데 사실 이렇게만 보면 처음에는 잘 이해가 가지 않을 겁니다.

그래서 각각의 파트에 대한 주석을 다면 다음과 같습니다.

 

# 워크플로우의 이름을 설정합니다. GitHub Actions UI에서 이 이름으로 워크플로우를 식별할 수 있습니다.
name: Java CI with Gradle

# 이 워크플로우가 어떤 이벤트에 의해 트리거될지 정의합니다.
on:
  # 'push' 이벤트가 'main' 브랜치에 발생할 때 워크플로우가 실행됩니다.
  push:
    branches: [ "main" ]
  # 'pull_request' 이벤트가 'main' 브랜치에 대해 생성될 때 워크플로우가 실행됩니다.
  pull_request:
    branches: [ "main" ]

# 이 워크플로우에서 사용할 권한을 정의합니다. 여기서는 저장소의 콘텐츠를 읽을 수 있는 권한만 부여합니다.
permissions:
  contents: read

# 워크플로우에서 실행할 작업들을 정의합니다.
jobs:
  # 'build'라는 이름의 작업을 정의합니다.
  build:

    # 이 작업이 실행될 가상 환경을 지정합니다. 여기서는 최신 버전의 Ubuntu를 사용합니다.
    runs-on: ubuntu-latest

    # 작업을 수행할 단계들을 정의합니다.
    steps:
    # GitHub 저장소에서 코드를 체크아웃합니다. 이는 후속 단계에서 빌드하거나 테스트하기 위해 필요합니다.
    - uses: actions/checkout@v3
    # JDK 11을 설정합니다. Java 기반 프로젝트를 빌드하고 테스트하기 위해 필요합니다.
    - name: Set up JDK 11
      uses: actions/setup-java@v3
      with:
        java-version: '11'
        distribution: 'temurin'
    # Gradle을 사용하여 프로젝트를 빌드합니다. 이 단계에서는 빌드와 함께 테스트가 실행됩니다.
    - name: Build with Gradle
      uses: gradle/gradle-build-action@bd5760595778326ba7f1441bcf7e88b49de61a25 # v2.6.0
      with:
        arguments: build

 

 

여기까지 작성 후에 commit changes 버튼을 눌러 remote에서 commit을 만들어줍니다.

 

자 이제 CI 파이프라인 구축은 다 끝났습니다!

이제는 한번 확인해 보겠습니다.

4. CI 파이프라인의 실행 및 확인

파일을 커밋하고 푸시하면

test 용 빈 한줄 넣기

GitHub Actions는 자동으로 새로운 워크플로우를 실행하고

레포지토리 메인 화면에서 확인이 가능합니다.

자동으로 돌아가고 있는 build!

'Actions' 탭에서build의상태와 로그를 확인할 수 있습니다.

노란불, 돌아가는 스크립트

여기에서 성공, 실패, 오류 등의 상세 정보를 볼 수 있습니다.

성공적으로 끝나게 된다면 다음과 같은 화면을 확인할 수 있습니다.

Succeeded now!

 

5. 파이프라인 수정 및 유지보수

기존의 작업을 확인해보고 싶거나

요구사항이 변경되거나 새로운 테스트 케이스를 추가할 해야 할 때

Actions 탭으로 가 YAML 파일을 수정하여 CI 파이프라인을 업데이트합니다.

이전 작업 확인

이는 CI의 기본 원리에 따라, 프로젝트의 안정성을 지속적으로 유지하고 향상시키는 데 도움이 됩니다.

 

정리

오늘 지난 CI의 프로세스와 도구 선택이 이어 GitHub Actions로 실제 작업 프로세스에 대해 배워보았습니다.

질문이 있다면 언제든지 날려주세요!