[Deploy] CI/CD

rsuubinn·2023년 4월 3일

deploy

목록 보기

4/5

CI/CD

CI/CD의 단계

지속적 통합(Continuos Integration, CI)

개발자를 위한 자동화 프로세스라고 볼 수 있다.

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

이 과정에서 개발자는 코드를 잦게 원격 코드 저장소에 push하고, 테스트 및 빌드를 하며 빌드 결과를 통해 빌드가 성공했는지 실패했는지 확인을 하고, 통합 테스트 결과를 통해 개선 방안을 찾는다.
이 지속적인 통합 과정을 통해 개발자는 버그를 일찍 발견할 수 있고, 테스트가 완료된 코드에 대해 빠른 전달이 가능해지며 지속적인 배포가 가능해진다.

지속적 통합은 모든 코드 변화를 하나의 레포지토리에서 관리하는 것 부터 시작한다.
모든 개발팀이 코드의 변화를 확인할 수 있기 때문에, 투명하게 문제점을 파악할 수 있다.
그리고 잦은 풀 리퀘스트(pull request)와 머지(merge)로 코드를 자주 통합한다.
이 때, 기본적인 테스트도 작동시킬 수 있다.
이렇게 지속적 통합을 통해 개발팀은 각자 개발한 코드를 이른 시점에 자주 합치고 자주 테스트를 해볼 수 있다.

지속적 통합으로 보안 이슈, 에러 등을 쉽게 파악할 수 있어 해당 이슈를 빠르게 개선할 수 있다.
지속적 통합이 적용된 개발팀은 코드를 머지하기 전, 이미 빌드 오류나 테스트 오류를 확인하여 훨씬 더 효율적인 개발을 할 수 있게 됐다.

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

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

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

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

배포 자동화

: 한 번의 클릭 혹은 명령어 입력을 통해 전체 배포 과정을 자동으로 진행하는 것

배포 자동화가 필요한 이유
1. 먼저 수동적이고 반복적인 배포 과정을 자동화함으로써 시간이 절약된다.
2. 휴먼 에러(Human Error)를 방지할 수 있다.
휴먼 에러 : 수동적으로 배포 과정을 진행하는 중에 생기는 실수들

CI/CD 파이프라인

: 수없이 진행되는 배포 과정을 자동화시키는 방법

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

파이프라인(Pipeline) : 소스 코드의 관리부터 실제 서비스로의 배포 과정을 연결하는 구조
파이프라인은 전체 배포 과정을 여러 단계(Stages) 로 분리한다.
각 단계는 파이프라인 안에서 순차적으로 실행되며, 각 단계마다 주어진 작업(Actions) 들을 수행한다.

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

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

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

Github Actions

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

레포지토리에서 Pull Request 나 Push 같은 이벤트를 트리거로 GitHub 작업 워크플로(Workflow) 를 구성할 수 있다.
워크플로 는 하나 이상의 작업이 실행되는 자동화 프로세스로, 각 작업은 자체 가상 머신 또는 컨테이너 내부에서 실행된다.

워크플로는 .yml (혹은 .yaml) 파일에 의해 구성되며, 테스트, 배포 등 기능에 따라 여러 개의 워크플로도 만들 수 있다.
생성된 워크플로는 .github/workflows 디렉토리 이하에 위치한다.

간단한 예시

# 워크플로 이름
name: Bare Minimum Requirements

# 언제 job을 작동시킬지
on: [push, pull_request]

# 어떤 job을 할지(1개 이상의 작업)
jobs:
  # 테스트
  test:
    # 러너 : 윈도우, 맥, 우분투 등등
    runs-on: ubuntu-latest
    # 단계
    steps:
      # 실행하는 작업 선택 => 깃허브에 릴리즈된 버전 중에 특정 버전 참조
      - uses: actions/checkout@v3
      # 작업 단계 이름(소제목 같은)
      - name: Bare Minimum Requirements
        # 노드 버전 세틍하는 부분
        # 깃허브 actions의 node.js 환경 설정
        uses: actions/setup-node@v3
        with:
          node-version: '16'
      - run: npm install
      - run: npm test

실습

전에는 AWS S3에 직접 build된 파일을 업로드 했다면 이번엔 자동으로 업로드 되도록 하기 위해 실습을 진행해본다.

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 install
        working-directory: ./my-agora-states-client
      - name: Build
        run: npm run build
        working-directory: ./my-agora-states-client
      - name: SHOW AWS CLI VERSION
        # 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: |
          aws s3 sync \
            --region ap-northeast-2 \
            build s3://fe-28-rsuubinn-s3 \ 
            --delete
        working-directory: ./my-agora-states-client