[네트워크] 🔗CI / CD와 Github Actions 사용법

▷ CI

Continuous Integration - 지속적인 통합

개발자를 위한 자동화 프로세스라고 볼 수 있으며,
Code - Build - Test 단계에서 꾀할 수 있다.

Code : 개발자가 코드를 원격 코드 저장소에 push하는 단계
Build : 원격 코드 저장소로부터 코드를 가져와 유닛 테스트 후 빌드하는 단계
Test : 코드 빌드의 결과물이 다른 컴포넌트와 잘 통합되는 지 확인하는 과정

▷ CD

Continuous Delivery - 지속적인 서비스 제공
Continuous Deployment - 지속적인 배포

위 두 용어는 상호 교환적으로 사용하며,
Release - Deploy - Operate 단계에서 꾀할 수 있다.

Release : 배포 가능한 소프트웨어 패키지를 작성
Deploy : 프로비저닝을 실행하고 서비스를 사용자에게 노출(실질적인 배포 부분)
Operate : 서비스 현황을 파악하고 생길 수 있는 문제를 감지

지속적 배포의 경우, 코드 변경부터 프로덕션에 빌드 제공까지
자동화된 테스트와 코드 배포 과정을 포함한다. (ex. Github Page)

---

🔗 파이프 라인

자동화를 꾀하는 부분은 보통 코드가 빌드되면서 최종적으로 배포가 되는 단계이다. 이 부분을 지속적인 통합 및 배포를 위하여 일련의 자동화 단계로 만드는데, 이것을 파이프라인을 구축한다고 표현한다.

파이프라인에는 대표적으로 세 가지 단계가 존재한다.

단계	설명
1. Source 단계	원격 저장소에 관리되고 있는 소스 코드에 변경 사항이 일어날 경우, 이를 감지하고 다음 단계로 전달하는 작업을 수행한다.
2. Build 단계	Source 단계에서 전달받은 코드를 컴파일, 빌드, 테스트하여 가공한다. 또한 Build 단계를 거쳐 생성된 결과물을 다음 단계로 전달하는 작업을 수행한다.
3. Deploy 단계	Build 단계로부터 전달받은 결과물을 실제 서비스에 반영하는 작업을 수행한다.

파이프라인의 단계는 필요에 따라 더 세분화되거나 간소화될 수 있다.
(해당 툴을 소개하는 업체에 따라 용어를 미묘하게 다르게 사용하기도 함)

---

🔗 CI/CD 파이프라인 구성 요소 및 장점

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

실무에서는 이러한 반복적인 과정을 자동화하여 처리한다.

이렇게 구축된 파이프라인은 수동으로 하는 것보다 더 빠르고 안정적이며
시간을 효과적으로 줄여주고 CI/CD 인프라와의 호환성과 효율성을 높여준다.

---

▷ Github Actions

Github가 공식적으로 제공하는 빌드, 테스트 및 배포
파이프라인을 자동화할 수 있는 CI/CD 플랫폼이다.

레포지토리에서 Pull Request 나 push 같은 이벤트를
트리거로 GitHub 작업 워크플로(Workflow)를 구성할 수 있다.

워크플로우는 .yml 파일로 구성되며, 테스트나 배포 등
각각의 기능에 대해 워크플로우를 여러 개 생성할 수 있다.
(생성된 워크플로우는 보통 .github/workflows 디렉토리에 위치함)

❗️참고) 비공개 레포지토리의 경우 Github Actions가 작동할 때의 용량과 시간이 제한되어있으며 공개 레포지토리는 무료로 사용 가능하다.

---

🔗 YAML

Yet Another Markup Language

사람이 읽을 수 있는 데이터 직렬화 언어를 의미한다.

YAML은 사람이 읽을 수 있고 이해하기 쉽고
다른 프로그래밍 언어와 함께 사용할 수도 있다.

일반적으로 설정 파일(configure file 등)에 사용하기에 좋다.
(ex. YAML을 실제로 사용하는 곳 - 쿠버네티스 라이브러리)

---

🔗 YAML 문법

# : 주석
--- : 문서의 시작 (선택사항)
... : 문서의 끝 (선택사항)

--- #문서 시작

#이 사이에 내용이 들어간다.

... #문서 끝

기본 형태
key: value 이며, : 다음에는 무조건 공백 문자가 와야 한다.

자료형
int, string, boolean, 리스트, 매핑을 지원한다.

#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: Kim
  job: Developer
  skills: 
    - docker
    - kubernetes
  # JSON 형식의 "skill" : [docker, kubernetes]와 같다.

객체

key: 
  key: value
  key: value

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

Text

| : 줄바꿈 표현
> : 줄바꿈 무시 표현

# |는 줄바꿈
# JSON 형식의 "comment_line_break": "Hello world.\nIm Tata.\n"과 같다.
comment_line_break: |
  Hello world.
  Im Tata.

# >는 줄바꿈 무시
# 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:'

---

🔗 JSON vs YAML

	JSON 파일	YAML 파일
작성 형식	각 key-value 쌍을 "{}" 안에 작성	각 key-value 쌍을 "{}" 없이 작성 가능
계층 구조	중괄호 "{ }"로 감싸진 key-value 쌍들의 중첩 계층 구조를 가짐	들여쓰기로 key-value 쌍들의 중첩 계층 구조를 나타냄
주석 작성	주석 작성 불가능	주석 작성 가능
호환성	YAML은 JSON의 상위 호환 격이므로, JSON 문서를 그대로 사용 가능	기존 JSON 문서를 그대로 YAML 문서로 사용 가능하며, 상호 변환이 가능

# YAML
name: Bare Minimum Requirements
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3 # 실행하는 작업 선택 => 깃헙에 릴리즈된 버전
      - name: Bare Minimum Requirements #작업 단계
        uses: actions/setup-node@v3 #노드 버전 세팅하는 부분
        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"
      ]
    }
  ]
}

---

▷ Github Actions 사용법

우선, AWS에서 발급 받은 키를 등록해준다.

.github의 workflow 폴더 안에 cient.yml 파일을 생성한 뒤, 아래 코드를 추가한다.

name: client # workflow 이름
on: # 언제 작동할 것인가
  push: # push가 되면
    branches: # 어떤 브랜치에서?
      - main # main 브랜치에서
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout source code.
        uses: actions/checkout@v3
      - name: Install dependencies
        run: npm install # install 명령어
        working-directory: ./my-agora-states-client # 디렉토리 위치 설정
      - name: Build
        run: npm run build # build 명령어
        working-directory: ./my-agora-states-client # 디렉토리 위치 설정
      - name: SHOW AWS CLI VERSION
        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: |          # cd: 모든 파일을 복사하기 때문에 파일이 이미 존재하는 경우에도 그 파일을 복사
          aws s3 sync \ # sync: 파일을 복사하기 전에 경로를 확인하고 새 파일과 업데이트 된 파일만 복사
            --region ap-northeast-2 \
            build s3://버킷이름 \
            --delete
        working-directory: ./my-agora-states-client # 디렉토리 위치 설정

이제 브랜치 이름에 맞게 push 해주면 된다.

git push myRepo main

👉 Github Actions 공식문서