CI/CD | github actions

CI/CD

CI: 지속적 통합
CD: 지속적 배포 / 지속적 제공

지속적 통합

코드 변경을 공유 버전 관리 리포지토리에 자동으로 자주 통합하는 데 중점을 둡니다. 각 통합은 자동화된 빌드 및 테스트 프로세스를 트리거하여 개발 주기 초기에 문제를 감지합니다. CI는 서로 다른 팀 구성원의 코드 변경으로 인한 충돌 없이 코드 품질이 유지되도록 보장하여 개발자가 코드베이스의 안정성을 방해하지 않고 동시에 작업할 수 있도록 합니다.

지속적 배포/제공

지속적 제공

자동화된 테스트 통과 후 코드 변경 사항을 다양한 환경에 자동으로 제공하여 CI 프로세스를 확장한다
변경 사항을 프로덕션에 자동으로 push 하지 않고
배포되기 전 일종의 수동 개입에 의존하는 통제된 릴리스 프로세스를 제공한다
항상 배포가 가능한 상태로 유지되므로 언제든지 릴리스 할 수 있다

지속적 배포

지속적 배포는 지속적 제공에서의 수동 개입 없이
자동화된 테스트를 통과하는 즉시 프로덕션에 자동으로 배포하는 것을 말한다
신속하고 빈번한 릴리스를 목표로 하는 조직에 적합하다
자동화를 구성하는 인프라에 대한 높은 수준의 확신이 필요하지만 코드 변경과 가용성 사이의 리드 타임을 크게 줄일 수 있다

단순히 자동화하여 통합, 배포해준다라는 의미를 넘어 충돌 없이 코드 품질이 유지되고,
안정성에 방해받지 않고 동시에 작업할 수 있다는 부분이
전체 작업 태스크를 방해하지 않는 안정적인 개발 환경을 만들어 줄 수 있다는 점에서 중요한 것 같다

복잡성을 줄여주고 많은 책임을 자동화 한다
효율성을 극대화 시키고, 오류 감지 도구를 통해 근본적인 원인을 정확히 찾아낼 수 있다
모든 코드의 스냅샷에 초점을 맞춰 안정성 테스트를 하기 때문에 결함이 즉시 처리되므로 백로그가 줄어든다

고객 경험도 개선될 수 있다

자동화를 통해 개발자가 조금 더 서비스에 가까운 문제 해결에 집중할 수 있다

github action

깃허브에서 제공하는 워크플로우 자동화 서비스 action
저장소 관련 프로세스와 작업을 자동화 한다

깃허브 액션에서 제공하는 자동화는 크게 두가지다

• CI/CD
• 코드와 저장소 관리

action 의 구성

• workflow

• job

• step

  workflow 는 자동화 프로세스 시 가장 먼저 빌드 또는 생성되고 하나 이상의 job 을 포함, 트리거 이벤트 등도 포함될 수 있다
  job 은 runner 를 정의하고 하나 이상의 step 을 포함할 수 있다 step 은 runner 환경에서 실행될 단계를 정의한다
  job 은 기본적으로 병렬로 처리되지만 동기적으로 실행을 구성할 수도 있다
  특정 조건에따라 실행되도록 설정할 수 있다

step 은 하나의 작업 단위로 여러개로 구성될 수 있다
step 은 하나 이상으로 구성되어야 하고 순차적으로 실행된다
특정 조건에따라 실행되도록 설정할 수 있다

action

깃허브에는 이미 action 이라는 것이 구현되어 있다
우리는 워크플로우를 생성하여 내부 동작을 구성하면 된다

깃허브에서 Actions 탭을 클릭하면
제공되는 많은 워크플로우 구성들이 있고
개인적으로 구현할 수도 있다

직접 파일을 구성할 때는 저장소 최상단에
.github/workflows 폴더 생성 후
.yml 파일을 만들어 내부에 워크플로우를 구성할 수 있다

깃허브에서 기본으로 제공하는 basic workflow

# This is a basic workflow to help you get started with Actions

name: CI

# Controls when the workflow will run
on:
  # Triggers the workflow on push or pull request events but only for the "main" branch
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

  # Allows you to run this workflow manually from the Actions tab
  workflow_dispatch:

# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
  # This workflow contains a single job called "build"
  build:
    # The type of runner that the job will run on
    runs-on: ubuntu-latest

    # Steps represent a sequence of tasks that will be executed as part of the job
    steps:
      # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
      - uses: actions/checkout@v4

      # Runs a single command using the runners shell
      - name: Run a one-line script
        run: echo Hello, world!

      # Runs a set of commands using the runners shell
      - name: Run a multi-line script
        run: |
          echo Add other actions to build,
          echo test, and deploy your project.

workflows

.yml 파일은 들여쓰기로 코드 블록을 구분한다

1. name: 워크플로우의 키가 될 이름 설정
2. on: 실행 시기 설정 (이벤트 트리거 설정 - 수동으로 설정 할 수도 있다)
3. jobs: 작업 키를 이용해 작업 분야 정의
4. jobs 하위에 작업 분야의 이름 설정
5. runs-on: 설정된 이름 하위에 위치하는 실행 키
6. runs-on 에 작업 환경인 runner 설정 (각 OS 에 해당하는 runner 중 선택할 수 있다)
7. steps: - 로 구분된 작업 목록의 키 작성 (shell 스크립트나 미리 정의된 액션을 사용할 수 있다)
8. run: 작업 내용 작성
9. 작성된 내용 commit

name: First Workflow
on: workflow_dispatch
jobs: 
  first-job:
    runs-on: macos-latest
    steps: 
      - name: Print greeting
        run: echo "Hello World!"
      - name: Print Goodbye
        run: | 
        	echo "Done"
            echo "Bye!"

run 에서 여러줄 입력 시 | 기호를 사용한다

github action 의 workflows 는 코드의 일부로
커밋을 하여 변경 사항을 기록한다

변경사항 기록 후 Actions 탭으로 가면
Workflows 하위에 작성한 워크플로우 name 이 있고
run workflow 버튼이 있다

현재는 작성한대로 workflow_dispatch 로 이벤트 트리거가 설정되어 있으므로 수동으로 트리거 할 수 있다
run 버튼을 눌러서 실행 가능

Events (Workflow Triggers)

깃허브 액션의 워크플로우를 트리거할 수 있는 이벤트는 다양하다

• commit
• push (브랜치 정의 가능)
• pull_request
• create (branch or tag)
• fork
• issues
• workflow_dispatch
• repository_dispatch (REST API request)
• schedule
  등

워크플로우는 저장소에서 쉽게 관리할 수 있지만
저장소 내에서 실행되는 것은 아니다
github server 에서 작동된다
때문에 저장소 내부 작업을 해야할 경우 깃허브 서버에 저장소의 정보를 불러오는 작업을 해야한다
러너를 직접 작성하여 작업할 수 있지만
이미 구성된 내용이 공개되었을 경우 공개된 러너를 사용하는 것이 일반적이다

steps 에서 uses 키워드로 공개된 액션을 가져올 수 있다
공개된 액션을 사용할 때는 중간에 버전이 변경될 수 있기 때문에 버전을 고정하여 사용하는 것이 유리하다

with 키워드로 가져온 액션에서 설정을 추가할 수 있다

name: Test Project
on: push
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Get code
        uses: actions/checkout@v3
      - name: Install NodeJS
        uses: actions/setup-node@v3
        with:
          node-version: 18
      - name: Install dependencies
        run: npm ci
      - name: Run tests
        run: npm test

github action 에서는 빌드 또한 시뮬레이션 테스트 할 수 있다

여러개의 job 을 주어도 병렬로 처리되기 때문에
전체 시간은 꽤 빠르게 마무리 된다

needs: 키워드를 사용하면 해당 job 이 실행되기 전에 완료되어야 할 다른 job 을 명시할 수 있다
리스트로 묶어서(대괄호) 여러 작업을 명시할 수 있다
완료 시점을 정해주기 때문에 동기적으로 실행된다

트리거를 정하는 on: 키워드에도 리스트로 묶어서 모두 발생했을 시에만 작동하게 만들 수 있다

on: [push, workflow_dispatch]

이렇게 하면 push 또는 run 버튼으로 실행할 수 있게 된다

Expressions & Context Objects

Context Obejects

: jobs 와 steps 에 전달되는 메타 데이터를 말한다
깃허브의 동작은 컨텍스트 데이터를 생성한다
이벤트 트리거나 실행에 관한 정보를 담고 있다

Event Acitivity Types & Filters

이벤트에 다양한 조건등을 설정하여 관리할 수 있다

• Activity Types:
  pr 요청이 열렸을 때, 닫혔을 때 등 이벤트 세부 사항에 대해 제어 및 기본 동작 재설정
• Filters:
  타겟 브랜치 설정 등의 제어

Activity Types

on: 하위에 pull_request: 등의 이벤트 정의 후
types: 로 세부 사항을 설정할 수 있다
types: 역시 리스트로 Activity Types 을 여러개 받을 수 있다
types 가 없는 worklofw_dispatch: 에 대해서는
콜론으로 마무리하고 넘어갈 수 있다