[백엔드온라인TIL] github Action과 ci/cd (54일차)

Github Action 이란?

 

GitHub Actions는 GitHub에서 제공하는 서비스로, 빌드, 테스트, 배포 파이프라인을 자동화할 수 있는 CI(Continuous Integration, 지속 통합)와 CD(Continuous Deployment, 지속 배포) 플랫폼입니다. GitHub Actions를 사용하면 GitHub 리포지토리에서 손쉽게 CI/CD 결과를 확인하고 관리할 수 있습니다. 또한, YAML 포맷을 사용하여 가독성이 높고, 이미 구현되어 있는 수많은 액션을 활용하여 간단하게 CI/CD 플로우를 작성할 수 있습니다.

 

 

지속적 통합(Continuous Integration, CI)

현대적인 애플리케이션 개발에서는 여러 개발자들이 동일한 애플리케이션의 각기 다른 기능을 동시에 작업할 수 있도록 하는 것을 목표로 합니다. 그러나 조직에서 특정한 날("병합의 날(merge day)")을 정해 모든 분기 소스 코드를 병합하는 경우, 결과적으로 반복적인 수작업에 많은 시간을 소모하게 됩니다. 이렇게 반복적인 수작업을 하는 이유는 독립적으로 작업하는 개발자가 애플리케이션에 변경 사항을 적용할 때 다른 개발자가 동시에 적용하는 변경 사항과 충돌할 가능성이 있기 때문입니다. 이는 팀이 하나의 클라우드기반 통합 개발 환경(Integrated Development Environment, IDE)사용에 동의하는 대신 각 개발자가 각자의 로컬 IDE를 커스터마이징하는 경우 더욱 복합적인 문제가 될 수 있습니다.

CI(지속적 통합)를 통해 개발자들은 코드 변경 사항을 공유 브랜치 또는 "트렁크"로 다시 병합하는 작업을 더욱 수월하게 자주 수행할 수 있습니다. 개발자가 애플리케이션에 적용한 변경 사항이 병합되면 이러한 변경 사항이 애플리케이션을 손상시키지 않도록 자동으로 애플리케이션을 구축하고 각기 다른 레벨의 자동화된 테스트(일반적으로 단위 테스트 및 통합 테스트) 실행을 통해 변경 사항이 애플리케이션에 제대로 적용되었는지를 확인합니다. 다시 말해, 클래스와 기능에서부터 전체 애플리케이션을 구성하는 서로 다른 모듈에 이르기까지 모든 것에 대한 테스트를 수행합니다. 자동화된 테스트에서 기존 코드와 신규 코드 간의 충돌이 발견되면 CI를 통해 이러한 버그를 더욱 빠르게 자주 수정할 수 있습니다.

 

-> 코드 머지를 용이하게 한다. 

 

지속적 제공(Continuous Delivery, CD)

CI의 빌드 자동화, 유닛 및 통합 테스트 수행 후, 이어지는 지속적 제공 프로세스에서는 유효한 코드를 리포지토리에 자동으로 릴리스합니다. 그러므로 효과적인 지속적 제공 프로세스를 실현하기 위해서는 개발 파이프라인에 CI가 먼저 구축되어 있어야 합니다. 지속적 제공의 목표는 프로덕션 환경으로 배포할 준비가 되어 있는 코드베이스를 확보하는 것입니다.

지속적 제공의 경우, 코드 변경 사항 병합부터 프로덕션에 적합한 빌드 제공에 이르는 모든 단계에는 테스트 자동화와 코드 릴리스 자동화가 포함됩니다. 이 프로세스를 완료하면 운영팀이 더욱 빠르고 손쉽게 애플리케이션을 프로덕션으로 배포할 수 있게 됩니다.

 -> 테스트 자동화를 용이하게 한다. 

 

-> ci/cd 의 마지막 단계는 배포작업 자동화 

 

 

Github Acitons 세부 개념 정리 

 

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

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

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

.github/workflows/example.yml

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

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

.github/workflows/hello

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

 

 

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

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

 

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

.github/workflows/example.yml

# ...(생략)...

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

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

 

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

# ...(생략)...

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

작업에서 가장 중요한 부분은 작업 순서를 정의하는 것일텐데요. 

 

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

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

 

 

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

.github/workflows/example.yml

# ...(생략)...

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

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

 

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

GitHub에서 제공하는 대표적인 공개 액션으로 바로 위 예제에서도 사용했던 체크 아웃 액션(actions/checkout)을 들 수 있는데요. 대부분의 CI/CD 작업은 코드 저장소로 부터 코드를 작업 실행 환경으로 내려받는 것입니다.

 

 

정리

 

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

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

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