S4 unit10 | CI/CD란? Github Action으로 자동 파이프라인 구축

📌 CI/CD 간단 정의

CI  :  지속적인 통합 (Continuous Integration)

애플리케이션에 대한 새로운 코드 변경 사항이 정기적으로 빌드 및 테스트되어 공유 레포지토리에 통합된다.

즉, 여러 명의 개발자가 동시에 애플리케이션 개발과 관련된 코드 작업을 할 경우 충돌하는 문제를 해결할 수 있다.

 

CD  : 지속적인 서비스 제공 (Continuous Delivery), 지속적인 배포 (Continous Deployment) 

CD는 지속적인 서비스 제공과 지속적인 배포 두 가지를 의미하며 두 용어는 상호 교환적으로 사용된다.

두 가지 의미 모두 파이프라인의 추가 단계에 대한 자동화를 뜻하지만 때로는 얼마나 많은 자동화가 이루어지고 있는지를 설명하기 위해 별도로 사용되기도 한다.

 

---

📌 지속적 통합 (Continuous Integration, CI)

개발자를 위한 자동화 프로세스

Code - Build - Test 단계에서 가능

 

Code :  개발자가 코드를 원격 코드 저장소에 push하는 단계

Build : 원격 코드 저장소로부터 코드를 가져와 유닛 테스트 후 빌드하는 단계

Test : 코드 빌드의 결과물이 다른 컴포넌트와 잘 통합되는지 확인하는 단계

 

지속적 통합은 모든 코드 변화를 하나의 레포지토리에서 관리하는 것 부터 시작

 

💎 장점 

• 모든 개발팀이 코드의 변화를 확인할 수 있기 때문에 투명하게 문제점을 파악할 수 있다.
• 테스트가 완료된 코드에 대해 빠른 전달이 가능하다.

 

📌 지속적 배포 (Continuous Delivery/Deployment, CD)

Release - Deploy - Operate 단계에서 가능

 

Release : 배포 가능한 소프트웨어 패키지를 작성

Deploy : 프로비저닝을 실행하고 서비스를 사용자에게 노출. 실질적인 배포 단계

Operate : 서비스 현황을 파악하고 생길 수 있는 문제를 감지

 

코드 변경 사항의 병합부터 프로덕션에 적합한 빌드 제공에 이르는 모든 단계로, 테스트 자동화와 코드 배포 자동화가 포함됨.

 

💎 장점

• 프로덕션 준비가 완료된 빌드를 코드 레포지토리에 자동으로 배포할 수 있기 때문에 운영팀이 보다 빠르고 손쉽게 애플리케이션을 프로덕션으로 배포할 수 있게 된다.

 

최근에는 지속적 통합과 지속적 배포가 빠른 속도로 진행되며 CI/CD를 하나로 묶어서 다루는 경우가 점차 증가하고 있다.

고객의 피드백을 빨리 받기 위해, 서비스를 중단하지 않기 위해 릴리즈만 잘 기록해두고 바로바로 배포하기도 한다.

뱅크샐러드 - 하루에 1000번 배포하는 조직 되기

---

📌 배포 자동화

전체 배포 과정을 자동으로 진행하는 것

• 휴먼 에러 방지
• 반복적인 배포과정 자동화함으로써 시간 절약

📌 CI/CD 파이프라인

1. 배포 자동화 방법 구축한 것

2. 소스 코드의 관리부터 실제 서비스로의 배포 과정을 연결하는 구조

도식화 된 배포과정

 

보통 자동화는 코드가 빌드되면서 최종적으로 배포가 되는 단계까지 이루어진다.

이 부분을 자동화 단계로 만드는 것을 파이프라인을 구축한다고 표현한다.

 

파이프라인 구성하는 기본 단계와 수행 작업

 

 

파이프라인은 전체 배포 과정을 여러 단계(Stages)로 분리한다. 

각 단계는 파이프라인 안에서 순차적으로 실행되며, 각 단계마다 주어진 작업(Actions)들을 수행한다.

 

📌 파이프라인의 대표적 3 단계

Source 단계

: 원격 저장소에 관리되고 있는 소스 코드에 변경 사항이 일어날 경우, 이를 감지하고 다음 단계로 전달하는 작업을 수행

Build 단계

: Source 단계에서 전달받은 코드를 컴파일, 빌드, 테스트하여 가공하고 생성된 결과물을 다음 단계로 전달

Deploy 단계

: Build 단계로부터 전달받은 결과물을 실제 서비스에 반영

 

 

📌 파이프라인 구성 요소

• 빌드 (소프트웨어 컴파일)
• 테스트 (호환성 및 오류 검사)
• 릴리스 (버전 제어 저장소의 애플리케이션 업데이트)
• 배포 (개발에서 프로덕션 환경으로의 변환)
• 규정 준수 및 유효성 검사

---

📌 Github Action으로 파이프라인 구축하기

Github Action 공식문서

 

1. public 레포지토리 생성

public으로 만들어야 Github Action을 무료로 이용할 수 있다.

 

2. .github/workflows 에 yml이나  yaml 파일 생성

3. 파일 작성

 

예시

# .github/workflows/client.yml
name: client
on:
  push:
    branches:
      - reference
jobs:
  build:
    runs-on: ubuntu-20.04
    steps:
      - name: Checkout source code.
        uses: actions/checkout@v2
      - name: Install dependencies
        run: npm i
        working-directory: ./my-agora-states-client
      - name: Build
        run: npm run build
        working-directory: ./my-agora-states-client
      - name: SHOW AWS CLI VERSION
        env:
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          AWS_EC2_METADATA_DISABLED: true
        run: |
          aws --version
      - name: Sync Bucket
        env:
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          AWS_EC2_METADATA_DISABLED: true
        run: |
          aws s3 sync \
            --region ap-northeast-2 \
            build s3://fe-81-2realzoo-s3 \
            --delete
        working-directory: ./my-agora-states-client

4. 작성 후 필요 시 시크릿 생성

---

📌 YAML 

YAML 파일 예시

name: Bare Minimum Requirements
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Bare Minimum Requirements
        uses: actions/setup-node@v1
        with:
          node-version: '16'
      - run: npm install
      - run: npm test

JSON 파일 예시

{
  "squadName": "Super hero squad",
  "homeTown": "Metro City",
  "formed": 2016,
  "secretBase": "Super tower",
  "active": true,
  "members": [
    {
      "name": "Molecule Man",
      "age": 29,
      "secretIdentity": "Dan Jukes",
      "powers": [
        "Radiation resistance",
        "Turning tiny",
        "Radiation blast"
      ]
    }
  ]
}

	YAML	JSON
key-value 형태	O	O
계층 구조	O	O
큰따옴표 사용	X (설정을 위한 스펙이나 프로퍼티 값 등이 JSON 파일에 비해 한 눈에 들어옴)	O
{} 형태	X (스코프의 압박이 없음)	O
주석 작성	O	X

YAML은 JSON의 상위 호환 격이므로 서로 변환이 가능하다.

 

YAML 문법

# : 주석

--- : 문서의 시작 (선택사항)

... : 문서의 끝 (선택사항)

들여쓰기 : 스페이스 키 2칸

 

기본표현

key: value이며, : 다음에는 무조건 공백 문자가 와야 함

 

자료형

int, string, boolean, 리스트, 매핑을 지원함

int, string 타입은 스칼라(Scalar)라 부르고, 배열(리스트)은 시퀀스(Sequence)라고 부름

매핑에는 기본 표현인 key-value 쌍 및 hash, dictionary가 포함됨

#int(숫자)
int_type: 1

#string(문자열)
string_type: "1"

#blooean(참/거짓)
boolean_true_type: true
boolean_false_type: false

#이외에 yes, no로 작성하기도 합니다.
yaml_easy: yes
yaml_difficult: no

#리스트(배열 형태)
person:
  name: Chungsub Kim
  job: Developer
  skills: 
    - docker
    - kubernetes
  # JSON 형식의 "skill" : [docker, kubernetes]와 같습니다.

 

객체

key 작성 후 두 칸을 들여써서 key-value 형태로 작성을 해주거나,

key를 작성 후 중괄호({})로 한 번 묶고 key-value형태로 작성

key: 
  key: value
  key: value

#또는 이렇게도 작성합니다. 가독성을 위해 사용합니다.
key: {
  key: value,
  key: value
}

 

Text

| : 줄바꿈 표현

> : 줄바꿈 무시 표현

 

# |는 줄바꿈 표현입니다.
# JSON 형식의 "comment_line_break": "Hello codestates.\nIm kimcoding.\n"과 같습니다.
comment_line_break: |
  Hello codestates.
  Im kimcoding.

# >는 줄바꿈 무시 표현입니다.
# JSON 형식의 "comment_single_line": "Hello world my first coding."과 같습니다.
comment_single_line: >
  Hello world
  my first coding.

 

문자열 따옴표

key-value 쌍에서 value에 :가 들어간 경우는 반드시 따옴표가 필요

# error가 납니다.
windows_drive: c:

# 이렇게 써야 합니다.
windows_drive: "c:"
windows_drive: 'c:'