CI CD와 Github Action

• 작성자: J045_김영호

---

CI/CD

• 참고자료

  https://www.ciokorea.com/insider/233289

  https://tecoble.techcourse.co.kr/post/2021-08-14-ci-cd/

  https://www.martinfowler.com/articles/continuousIntegration.html

CI/CD(Continuous Integration / Continuous Delivery · Deployment, 지속적 통합 및 지속적 제공) 은 개발자가 자주, 안정적으로 코드 변경을 제공하기 위해 사용하는 문화와 운영원칙, 일련의 작업 방식을 의미한다. DevOps 및 애자일 방법론의 권장 사항이다.

우리의 애플리케이션을 사용자에게 제공하기 위해 우리가 작성한 코드를 컴파일하고, 빌드한 뒤 배포를 거쳐야 한다. 이렇게 배포한 애플리케이션에 대한 오류 유무를 판단하기 위해 여러 테스트를 거치곤 해야한다. 이러한 반복적이고, 실수가 생길 가능성이 있는 작업들을 간단하게 하기 위해 CI/CD를 활용한다.

이를 통해 개발팀은 코드 품질과 소프트웨어 보안을 보장함과 동시에 비즈니스 요구사항을 충족하는데 집중할 수 있다.

CI (Continuous Integration)

CI, 지속적 통합은 개발팀 내에서 각자의 작업물을 하나로 통합하기 위한 소프트웨어 개발 방법론이다. 각 통합은 테스트를 포함한 자동화된 빌드를 통해 각 작업물을 검증할 수 있다. 지속적 통합이라는 개념은 익스트림 프로그래밍 개발 프로세스에서 유래하였다.

CI가 없는 경우, 모든 개발이 종료된 뒤에 컴파일/빌드/배포를 거쳐야 오류 여부를 검증하고 수정을 할 수 있었다. 하지만, CI를 도입함으로써 각 개발자는 기능을 구현하고, 이를 main 브랜치에 병합하여 그때그때 빌드함으로써 버그 유무를 빠르게 판단할 수 있다.

이러한 통합 과정, 다시 말해 컴파일/빌드/배포 과정과 테스트를 직접 수행하는 것은 시간 소모가 크기 때문에, 이를 자동화하여 빌드 가능 여부 / 오류 유무를 자동으로 검증할 수 있다.

즉, CI를 도입함으로써 버그를 빠르게 파악할 수 있고, 소프트웨어 품질 개선 및 업데이트 검증 및 릴리즈를 신속하게 할 수 있다.

Martin Fowler는 CI를 위해 최소한 다음 조건을 만족해야한다고 한다.

• 빌드 자동화 구축
• 테스트 자동화
• 커밋 빌드 속도 향상
• 처음부터 프로젝트에 CI 도입. 빌드 시간이 길어지기 시작하면 즉시 조치를 취할 것.

CD (Continuous Delivery / Deployment)

CD(Continuous Delivery / Deploy, 지속적 제공 / 배포) 는 제공할 소프트웨어를 항상 신뢰 가능한 수준에서 배포될 수 있도록 관리하는 것을 의미한다.

지속적 제공 은 앞서 CI를 통해 소스코드의 빌드 및 버그 파악을 성공적으로 진행한 경우, 이를 저장소에 업로드하는 것을 의미하여, 지속적 배포는 저장소에 업로드한 것을 배포환경에 릴리즈하는 것을 의미한다.

---

GitHub Action

Github Action이란

빌드와 테스트, 배포 파이프라인을 자동화할 수 있는 CI/CD 플랫폼이다. 각 PR에 대한 빌드와 테스트를 진행하거나 병합된 PR을 프로덕션으로 배포하는 워크플로우를 생성할 수 있다.

Github Action은 DevOps 그 이상을 바라보고 있으며, 레포지토리에 다른 이벤트가 발생하였을 때 워크플로우를 실행할 수 있도록 해준다. 깃허브는 리눅스, 윈도우, MacOS 가상 머신을 이용하여 워크플로우를 실행할 수 있고, 혹은 독립적으로 운영하는 서버를 연결하여 실행시킬 수 있다.

GitHub Action 구성요소

특정 이벤트에 대한 깃헙 액션 워크플로우를 작성하는 경우, 각 워크플로우는 병렬적으로, 혹은 절차적으로 실행할 하나 이상의 Job을 갖는다. 각 Job들은 Runner라고 부르는 가상 머신, 혹은 Container 내에서 동작하며, Job들은 각각 하나 이상의 Step들을 갖는다. Step은 작성한 스크립트를 실행하거나, 워크플로우 간소화를 위해 Action 이라는 재사용 익스텐션을 실행할 수 있다.

그림) Github Action Workflow (출처: https://docs.github.com/en/actions/learn-github-actions/understanding-github-actions)

1. Workflow

하나 이상의 Job들을 실행하는, 설정 가능한 자동화 프로세스를 의미한다. 이들은 레포지토리 내의 YAML 파일로 정의할 수 있으며, 레포지토리 내에서 발생한 이벤트에 의해 실행되거나, 지정한 시간에, 혹은 수동으로 실행할 수 있다. 이들은 레포지토리의 .github/workflows 에 저장하며, 1개 이상 존재할 수 있다.

2. Events

워크플로우를 실행시킬 수 있는, 레포지토리 내에서의 특정 활동/동작(Activity)을 의미한다. Github에서 PR을 생성하거나, 스케쥴에 따라 실행하거나, 수동으로 이벤트를 일으킬 수도 있다.

3. Jobs

같은 Runner에서 실행되는, 워크플로우 내에 존재하는 Step 집합을 의미한다. 각 Step은 실행할 쉘 스크립트나 Action을 뜻한다. Step들은 순서대로 실행하며, 다른 Step에 의존성을 갖는다. 각 Step들은 같은 Runner에서 실행되기 때문에, Step 간 데이터 공유가 가능하다.

일반적으로 Job들은 다른 Job들과의 의존성을 갖지 않지만, 의존성을 갖도록 설정할 수 있다. 이 경우, 의존성이 있는 Job이 종료될 때까지 Job 실행을 대기한다.

4. Actions

복잡하고 자주 반복하는 작업을 실행하는, Github Action을 위한 사용자 정의 Application이다. 이는 재사용을 통해 워크플로우에서의 반복적인 코드 작성을 줄일 수 있다. 이를 이용하면 Github에서 레포지토리를 pull하거나, 빌드 환경에서 쓰일 toolchain을 설치하거나, 클라우드 제공자에 대한 인가를 수행할 수 있다.

Action은 직접 작성할 수도 있고, Github Marketplace에서 다운로드받을 수 있다.

5. Runners

워크플로우를 실행할 서버를 의미한다. 각 Runner는 한번에 단 하나의 Job만을 실행할 수 있다. Github는 워크플로우 실행을 위해 우분투 리눅스, 윈도우, 맥OS 가상 머신을 제공한다. 이를 이용하면 각 워크플로우들은 새로운 가상 머신 내에서 동작한다. Github는 거대한 설정을 위해 large runner를 제공할 수도 있다.

만약 위에서 제공하는 OS 외에 다른 것을 쓰고자 하거나, 특정 하드웨어 설정이 필요한 경우 직업 Runner를 세팅하여 연결할 수 있다.

Workflow 작성에 대하여

하단의 yaml 파일을 기준으로 보자.

name: learn-github-actions
run-name: ${{ github.actor }} is learning GitHub Actions
on: [push]
jobs:
  check-bats-version:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: '14'
      - run: npm install -g bats
      - run: bats -v

• name (Optional)
  • Github Action 탭에서 보여질 워크플로우 이름
• run-name (Optional)
  • Github Action 탭에서 보여질 워크플로우 Run 이름
• on
  • 워크플로우를 위한 Trigger(Event)를 정의한다.
  • 위의 예시의 경우 push 가 발생할 때마다, PR을 Merge할 때마다 워크플로우가 실행된다. 별다른 Branch를 지정하지 않은 경우 모든 브랜치에 대한 push에 대해 워크플로우가 실행된다.
• jobs
  • 해당 워크플로우 내에서 실행할 Job 목록을 정의한다.
• check-bats-version (job 명칭)
  • ‘check-bats-version’이라는 job을 정의한다.
  • 하위에 정의되는 것들은 해당 job의 property를 의미한다.
  • runs-on
    • 어떤 OS에서 동작할 것인지 정의한다.
    • https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idruns-on 참고
  • steps
    • 속한 Job 내에서 실행할 모든 step들을 정의한다. 각 job들은 개별 action이거나 쉘 스크립트를 뜻한다.
    • -use

      • job 내에서 step으로써 사용할 Action을 지정한다. 이를 이용하면 본인의 레포지토리에 정의한 Action을 워크플로우처럼 사용하거나, 공개 레포지토리, 혹은 Docker 컨테이너 이미지 내에 정의된 Action을 사용할 수도 있다.

      • 이를 사용할 경우 반드시(까지는 아니지만) 사용할 Action의 버전을 함께 적어야한다. 버전이 제공되지 않는다면, 의도하지 않은 동작이 발생하거나 워크플로우가 깨질 수 있다. 일반적으로 Version은 Git Ref, SHA, Docker 태그로 정의할 수 있다.

        steps:
          # Reference a specific commit
          - uses: actions/checkout@a81bbbf8298c0fa03ea29cdc473d45769f953675
          # Reference the major version of a release
          - uses: actions/checkout@v3
          # Reference a specific version
          - uses: actions/checkout@v3.2.0
          # Reference a branch
          - uses: actions/checkout@main

      • 일부 Action들은 with 키워드를 통해 입력을 요구하기도 한다. 예시의 - uses: actions/setup-node@v3 가 그러한 것으로, 이는 설치할 node 버전을 with로 제공해주어야만 한다.

      • Action들은 JS File이나 Docker Container 이다. Docker를 쓰는 경우 실행 환경은 리눅스가 되어야만 한다.

      • https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsuses

    • -run
      • 실행할 쉘 스크립트를 작성한다.
      • 자세한 사항은 https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions 을 참고한다.

Action 추가 방법

1. Marketplace Action 활용

Github의 Workflow Editor 기능을 사용하면 사이드바에 Marketplace에서 액션을 검색할 수 있다. 여기서 찾은 Action에서 Installation 하위의 코드를 복사하여 그대로 붙여넣으면 사용할 수 있다. 다만 해당 방법으로 Action을 이용할 경우 with로 입력을 받는지 반드시 확인해야 한다.

2. 동일 레포지토리 내 커스텀 Action 활용

동일 레포지토리의 경우 {owner}/{repo}@{ref} 혹은 ./path/to/dir 형식으로 작성하여 사용할 수 있다. 만약 다음과 같은 파일 구조가 있을 경우, 다음과 같이 작성할 수 있다.

|-- hello-world (repository)
|   |__ .github
|       └── workflows
|           └── my-first-workflow.yml
|       └── actions
|           |__ hello-world-action
|               └── action.yml

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      # This step checks out a copy of your repository.
      - uses: actions/checkout@v3
      # This step references the directory that contains the action.
      - uses: ./.github/actions/hello-world-action

이때 action.yml은 액션에 대한 메타데이터를 제공한다. 문법은 다음을 참고한다. ("[Metadata syntax for GitHub Actions](https://docs.github.com/en/actions/creating-actions/metadata-syntax-for-github-actions).")

3. 다른 레포지토리의 커스텀 Action 활용

이 경우 {owner}/{repo}@{ref} 형식으로 가져다 쓸 수 있다. 이때, Action은 공개 레포지토리에 저장된 것만 활용할 수 있다.

jobs:
  my_first_job:
    steps:
      - name: My first step
        uses: actions/setup-node@v3

4. Docker Hub 상의 컨테이너 참조

만약 Docker Hub에 배포된 도커 컨테이너 이미지 내에 정의된 Action을 활용할 경우, docker://{image}:{tag} 형식으로 지정해주어야 한다. 보통 이를 사용하기 전에 Docker container image의 정합성을 검토해봐야 한다.

jobs:
  my_first_job:
    steps:
      - name: My first step
        uses: docker://alpine:3.8

Action에 Input / Output 제공

종종 Action은 입력이 필요하거나, 출력을 해야할 필요가 있다. 이 경우 각 Action의 action.yml / action.yaml 파일에서 무엇을 필요로 하고, 무엇을 출력하는지 정의한다. 아래의 예시는 file-path 입력을 정의하며, results-file 출력을 정의한다.

name: "Example"
description: "Receives file and generates output"
inputs:
  file-path: # id of input
    description: "Path to test script"
    required: true
    default: "test-file.js"
outputs:
  results-file: # id of output
    description: "Path to results file"

워크플로우에 환경변수 선언

Github Action에는 각 워크플로우가 실행될 때 쓰일 기본 환경변수가 제공된다. 만약 직접 환경변수를 정의하고자 하는 경우, yaml 워크플로우 파일에 이를 정의할 수 있다. 환경변수는 워크플로우 전역(env), 혹은 특정 Job(jobs.<job_id>.env), 특정 Step(jobs.<job_id>.step[*].env)에 대해 정의할 수 있다. (dotenv를 쓰는 경우는 이를 활용할 수 있는지 검토해볼 것.)

name: Greeting on variable day

on:
  workflow_dispatch

env:
  DAY_OF_WEEK: Monday

jobs:
  greeting_job:
    runs-on: ubuntu-latest
    env:
      Greeting: Hello
    steps:
      - name: "Say Hello Mona it's Monday"
        run: echo "$Greeting $First_Name. Today is $DAY_OF_WEEK!"
        env:
          First_Name: Mona

Job 간 데이터 공유

만약 Job이 생성한 file을 다른 Job에서도 쓰고자 하거나, 나중에 이를 사용하고자 다른 곳에 저장하고자 한다면, 이를 GitHub에 Artifacts로 저장할 수 있다. 이는 코드를 빌드/테스트할 때 생성된 파일들을 의미한다. 각 아티펙트는 바이너리/패키지 파일일 수도 있고, 테스트 결과이거나, 스크린샷, 또는 로그 파일일 수 있다. 이들은 자신들을 생성하는, 혹은 자신들을 사용하는 Job이 존재하는 워크플로우 실행과 연관되어있다. 하나의 실행에 존재하는 모든 Action과 워크플로우는 해당 실행에 대한 Artifact에 대한 쓰기 접근 권한을 갖는다.

다음과 같은 방식으로 결과 파일을 Artifact로 업로드할 수 있다.

jobs:
  example-job:
    name: Save output
    steps:
      - shell: bash
        run: |
          expr 1 + 1 > output.log
      - name: Upload output file
        uses: actions/upload-artifact@v3
        with:
          name: output-log-file
          path: output.log

Artifact는 다음과 같이 지정하여 다운로드할 수 있다. 다만 이 경우 with 키워드로 다운로드할 Artifact의 이름을 지정해주어야만 한다. 아래의 예시의 경우 output-log-file을 다운로드한다.

jobs:
  example-job:
    steps:
      - name: Download a single artifact
        uses: actions/download-artifact@v3
        with:
          name: output-log-file

주의할 것은, 한 실행 단위 내에서 같은 Artifact에 대한 업로드와 다운로드가 발생한다면, 다운로드하는 Job은 업로드하는 Job에 대한 의존성을 정의해야만 한다. 이는 jobs.<job_id>.needs: [Artifact Upload Job Id]를 통해 정의한다. ([참고](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idneeds))