CI/CD [Github Action]

전예훈·2023년 6월 6일
0

CI/CD란?

CI/CD는 약어로 몇가지의 다른 의미로 나눠지고 있다.

CI 는 개발자를 위한 자동화 프로세스인 지속적인 통합을 의미한다.
CI를 성공적으로 구현할 경우 애플리케이션에 대한 새로운 코드 변경 사항이 정기적으로 빌드 및 테스트되어 공유 레포지토리에 통합되므로 여러 개발자가 동시엔 애플리케이션 개발과 관련도니 코드 작업을 할 경우 서로 충돌할 수 있는 문제를 해결할 수 있다.

CD는 지속적인 서비스 제공 및 또는 지속적인 배포를 의미하며 이 두용어는 상호 교환적으로 사용되고 있다.
두 가지 의미 모두 파이프라인의 추가 단계에 대한 자동화를 뜻하지만 얼마나 많은 자동화가 이루어지고 있는지를 설명하기 위해 사용되고 있기도 하다.

지속적 통합

개발자를 위한 자동화 프로세스라고 볼수 있고 코드 -설계 - 구현 단계에서 적용되고있다.

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

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

지속적인 통합으로 보안 이슈, 에러 등을 쉽게 파알할 수 있어 해당 이슈를 빠르게 개선할 수 있다. 이전에는 각자 개발자가 작성한 코드를 합치고 난 후, 모두 모여서 빌드를 시작하고 나서야 문제점을 파악할 수 있었는데 지속적 통합 이적용된 개발팀은 코드를 머지 하기전, 이미 빌드 오류나 테스트 오류를 확인 해 훨씬 더 효율적인 개발을 할 수 있게 되었다.

지속적 배포

지속적인 서비스 제공 및 지속적인 배포를 의미하고 이 두 용어는 상호 교환적으로 사용하게 된다.

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

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

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


CI/CD 파이프 라인

개발자가 코드를 원격 저장소에 올리면 그 코드가 빌드 및 테스트와 릴리스를 거쳐 배포 서버로 전달되게 된다. 배포 서버에 도달한 빌드된 코드는 애플리케이션 서버로 최종 배포가 완료되고 그 결과물을 유저가 직접 확인하게 된다. 자동화를 꾀하는 부분이 보통 코드가 빌드되면서 최종적으로 배포가 되는 단계이고 이부분을 지속적인 통합 및 배포를 위하여 일련의 자동화 단계로 만드는데 이것을 파이프라인을 구축한다 라고 표현한다.


GitHub Actions

GitHub Actions는 Github 가 공식적으로 제공하는 빌드, 테스트 및 배포 파이프라인을 자동화 할 수 있는 CI/CD 플랫폼이다. 레포지토리에서 pull Request 나 push 같은 이벤트로 Gihub 작업 워크플로우를 구성할수 있고 워크플로우는 하나 이상의 작업이 실행되는 자동화 프로세스로, 각 작업은 자체 가상 머신 또는 컨테이너 내부에서 실행되게 된다.

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

실습

만의 아고라 스테이츠 서버의 클라이언트 부분을 S3로 배포합니다.
튜토리얼에 이어서 해당 실습을 진행합니다. 기존에 가지고 있었던 레포지토리를 이용해 봅시다.

Github Actions를 통한 배포 Flow (클라이언트)

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

아고라 스테이츠 서버 레퍼런스를 GitHube Action 을 이용하였는데

먼저 내 계정의 새로운 레포지토리를 만들고

# 기존 나만의 아고라 스테이츠 서버 레퍼런스 클론
git clone git@github.com:codestates-seb/fe-sprint-my-agora-states-server-reference.git
# 디렉터리 이동
cd fe-sprint-my-agora-states-server-reference
# 새로운 리포지토리를 원격 리포지토리로 등록
git remote add myRepo git@github.com:{여러분의 아이디}/{새로운 리포지토리 이름}.git
# 기존 레퍼런스 코드를 새로운 리포지토리로 push
git push myRepo reference

새로운 리포지토리를 원격 리포지토리롤 등록한뒤에 새로운 코드를 push해준다

실습 배포 링크

http://fe-103-superrdeveloper-s3.s3-website.ap-northeast-2.amazonaws.com/login

profile
더욱더 QA스럽게!

0개의 댓글