[Deploy] CI/CD | github action으로 클라이언트 CI/CD를 구축하기(feat. AWS s3)

Eunji Lee·2023년 2월 3일
Front-end BootcampToday I learneddeploy
0

[TIL] Front-end

목록 보기
36/36
post-thumbnail

CI/CD

어플리케이션 개발 단계부터 배포까지의 단계를 자동화해서 애플리케이션을 효율적이고 빠르게, 더 자주 사용자에게 배포할 수 있도록 만드는 것


(출처: CI/CD(Continuous Integration/Continuous Delivery)란?)

CI(Continuous Integration)

의미

  • 개발자를 위한 자동화 프로세스인 지속적인 통합을 의미
  • CI 구현을 통해 애플리케이션에 대한 새로운 코드 변경 사항을 정기적으로 빌드 및 테스트하고, 공유 리포지토리에 머지할 수 있음

단계

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

Key Point

  • 개발자는 코드 변경사항을 주기적으로 빈번하게 공유 리포지토리에 머지함
  • 통합을 위한 단계(빌드, 테스트, 머지)가 자동적으로 일어남

장점

  • 개발 생산성을 높일 수 있음
    • 여러 명의 개발자가 동시에 애플리케이션 개발과 관련된 코드 작업을 할 경우 서로 충돌할 수 있는 문제를 해결할 수 있음
  • 버그 수정 용이
    • 머지되는 코드들은 자동으로 빌드되고 테스트되기 때문에 문제점을 빠르게 파악할 수 있고 이에 따라 버그도 빠르게 수정할 수 있음

CD(Continuous Delivery/Deployment)

의미

  • 지속적인 제공(Continuous Delivery) 및/또는 지속적인 배포(Continuous Deployment)를 의미하며 이 두 용어는 상호 교환적으로 사용됨
  • 두 가지 의미 모두 파이프라인의 추가 단계에 대한 자동화를 뜻하지만 때로는 얼마나 많은 자동화가 이루어지고 있는지를 설명하기 위해 별도로 사용되기도 함

지속적인 제공(Continuous Delivery)

  • 개발자들이 애플리케이션에 적용한 변경 사항이 버그 테스트를 거쳐 리포지토리(예: GitHub 또는 컨테이너 레지스트리)에 자동으로 업로드되는 것
  • 운영팀은 이 리포지토리에서 애플리케이션을 실시간 프로덕션 환경으로 배포할 수 있음
    • 즉, 지속적인 배포와는 달리, CI 이후 어플리케이션을 배포하기 전, 개발자나 검증팀이 직접 확인한 후 수동적으로 배포함
    • 개발팀과 비즈니스팀 간의 가시성 및 커뮤니케이션 부족 문제를 해결
    • 최소한의 노력으로 새로운 코드를 배포할 수 있음

지속적인 배포(Continuous Deployment)

  • 지속적 제공의 확장된 형태로, 애플리케이션을 프로덕션으로 릴리스하는 작업을 자동화함

장점

  • 수동 프로세스로 인한 운영팀의 프로세스 과부하 문제를 해결할 수 있음
    • 이를 통해 애플리케이션이 사용자에게 더욱 빠르게 제공될 수 있음
  • 사용자 피드백을 지속적으로 수신하고 통합하는 일이 훨씬 수월함
    • 개발자가 애플리케이션에 변경 사항을 작성한 후 몇 분 이내에 클라우드 애플리케이션을 자동으로 실행할 수 있기 때문
  • 애플리케이션 배포의 위험성이 적음
    • 애플리케이션 변경 사항을 한 번에 모두 릴리스하지 않고 작은 조각으로 세분화하여 릴리스할 수 있기 때문

단점

  • 많은 선행 투자가 필요
    • CI/CD 파이프라인의 여러 테스트 및 릴리스 단계를 자동적으로 수행할 수 있도록 테스트 자동화가 제대로 설계되어야 함


github action으로 클라이언트 배포하기

배포 단계

  1. Source: Github reference 브랜치에 코드가 커밋되면
  2. Build: github acitons의 YAML 파일에 적힌 명령어를 토대로 Webpack을 이용해 빌드를 하고
  3. Deploy: github acitons의 YAML 파일에 적힌 명령어를 토대로 s3로 빌드 결과를 업로드하기

주의사항

AWS_SECRET_ACCESS_KEY가 외부에 노출되면 안되기 때문에 Github actions Secrets 기능을 활용하여 환경 변수로 관리해준다.

튜토리얼
Github) Github actions에서 Secrets로 환경변수 관리하기

# .github/workflows/client.yml
name: client # 워크플로의 이름
on: # branches와 일치하는 분기, 즉 reference 브랜치에 푸시가 발생할 때만 워크플로가 실행되도록 필터 설정
  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: ./my-agora-states-client
      - name: Build # 소스코드 빌드하기(이를 통해 Build 폴더 생성됨)
        run: npm run build
        working-directory: ./my-agora-states-client
      - name: SHOW AWS CLI VERSION # AWS 버전 확인하기
        env: # Secrets을 활용해서 환경변수로 등록한 AWS Key가 사용됨
          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 # 생성된 build 폴더와 버킷 동기화하기
        env: # Secrets을 활용해서 환경변수로 등록한 AWS Key가 사용됨
          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://<s3 버킷 이름 넣기> \
            --delete
        working-directory: ./my-agora-states-client


참고자료
CI/CD(Continuous Integration/Continuous Delivery)란?
CI/CD 5분 개념 정리 (현업에서 쓰는 개발 프로세스)
Github Actions 알아보기 - 워크플로 정보

profile
Eunji Lee

0개의 댓글

관련 채용 정보