[FE_Bootcamp] 78일차

Frontend Study

[FE_Bootcamp] 78일차_CI/CD

킹경후 2023. 6. 5. 16:33

프론트엔드 공부를 하다 보면 단지 코드 한줄 정도를 바꾸었을 뿐인데 이를 다시 빌드하고, 파일을 업로드 한 뒤 재배포 해야 하는 불편함이 생긴다.

이러한 불편함을 해결하기 위해 등장한 것이 CI/CD를 통한 자동화 배포 기술이다.

CI/CD는 무엇이며, 이를 어떻게 이용하여 자동 배포를 할 수 있는지 알아보자

1. CI와 CD

A. CI

"CI"는 개발자를 위한 자동화 프로세스라고 볼 수 있으며, Code - Build - Test 단계를 거친다.

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

이 과정에서 개발자는 코드를 지속적으로 원격 코드 저장소에 push하고, 테스트 및 빌드를 하며 빌드 결과를 통해 빌드가 성공했는지 실패했는지 확인을 하고, 통합 테스트 결과를 통해 개선 방안을 찾는다.

이 지속적인 통합 과정을 통해 개발자는 버그를 일찍 발견할 수 있고, 테스트가 완료된 코드에 대해 빠른 전달이 가능해지며 지속적인 배포가 가능해진다.

B. CD

CD는 지속적인 서비스 제공(Continuous Delivery) 및 지속적인 배포(Continuous Deployment)를 의미하며 이 두 용어는 상호 교환적으로 사용된다. 이 부분은 Release - Deploy - Operate 단계를 거친다

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

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

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

2. 배포 자동화

다양한 프로그래밍 툴들과 라이브러리, 언어들이 개발되며 웹 개발자들은 사용자 업데이트에 대한 걱정에서도 벗어났고, 하루에 여러 번의 배포도 가능하게 되었다. 하지만 개발자가 배포할 때마다 일일이 빌드하고 배포하는 과정이 수없이 진행된다면 매우 번잡스럽고 지루할 것이다.

그래서 이 수없이 진행되는 배포 과정을 자동화시키는 방법을 구축하게 되는데, 그것을 CI/CD 파이프라인이라고 한다.

개발자가 코드를 원격 저장소에 올리면, 그 코드가 빌드 및 테스트와 릴리스를 거쳐 배포 서버로 전달된다.

배포 서버에 도달한 빌드된 코드는 애플리케이션 서버로 최종 배포가 완료되고, 그 결과물을 유저가 직접 확인하게 되는 것이다.

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

배포에서 파이프라인(Pipeline)이란 용어는 소스 코드의 관리부터 실제 서비스로의 배포 과정을 연결하는 구조를 뜻한다.

파이프라인은 전체 배포 과정을 여러 단계(Stages)로 분리하고, 각 단계는 파이프라인 안에서 순차적으로 실행되며, 각 단계마다 주어진 작업(Actions)들을 수행한다.

파이프라인을 여러 단계로 분리할 때, 대표적으로 쓰이는 세 가지 단계가 존재한다.

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

이렇게 구축된 파이프라인은 최신 버전의 소프트웨어 애플리케이션을 업데이트하고 제공하려는 일련의 처리 단계에 걸리는 시간을 수동으로 하는 것보다 더 빠르고 안정적이며 효과적으로 줄여주고 CI/CD 인프라와의 호환성과 효율성을 높일 수 있다.

3. Github Actions를 통한 CI/CD 실습

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

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

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

이 Github Actions를 통해 코드를 AWS로 배포해보자.

//원래 코드는 YALM으로 작성되었으나, 지원되지 않아 JS로 표기
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
        //필요한 dependencies 설치
        run: npm install
        working-directory: ./업로드할 디렉토리
      - name: Build
        //앱 빌드
        run: npm run build
        working-directory: ./업로드할 디렉토리
      - 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: |
          //AWS의 S3 클라우드에 업로드
          aws s3 sync \
            --region ap-northeast-2 \
            build s3://본인의 S3 이름 \
            --delete
        working-directory: ./업로드할 디렉토리

깃허브에 파일을 커밋하면, 설정한 파이프라인을 따라서 빌드, 테스트, 배포까지 순차적으로 진행된다.

과정에 문제가 있다면 빨간 X 표시가 뜨고, 문제가 없이 배포까지 진행 되었다면 초록색 체크 표시가 뜨게 된다.

배포가 성공적으로 진행되었다면 이렇게 원하는 웹 페이지를 띄울 수 있게 된다.