문제점 파악

프로젝트에서는 “판매자”와 “구매자”의 웹사이트가 각각 분리되어 배포되어 있었으며, 이로 인해 업데이트 과정에서 배포자가 직접 AWS에 접속하여 빌드된 파일을 업데이트하고, 무효화 처리까지 수행해야하는 불편함이 있었다. 이러한 문제는 배포 과정의 효율성을 저하시키는 요인이 되었으며, 우리팀은 문제를 이러한 문제를 해결하기 위해 자동 배포 시스템 도입을 결정하게 되었다.

기존의 배포 방식 Build → Upload to S3 → CloudFront Invalidation

<aside> 👉🏻 우리는 다양한 배포 시스템 중 GitHub Actions를 선택하게 되었는데, 그 이유는 다음과 같다.

1. 통합된 환경 : 우리팀의 프로젝트 관리는 GitHub를 이용하고 있었으며 추가적인 비용 없이 레포지토리 내에서 바로 워크플로우를 정의하고 관리할 수 있다.
2. 직관적인 설정 : 다른 ****CI/CD 도구에 비해 설정이 직관적이며, YAML 형식의 설정 파일을 사용하여 쉽게 워크플로우 를 정의할 수 있었다. </aside>

Git Action이란?

https://docs.github.com/ko/actions

GitHub Actions는 ”CI/CD와 같은 workflow를 자동화 할 수 있는 도구”라고 설명되어 있으며, 쉽게 말해 GitHub 내 어떤 이벤트(push, pull, merge ...)가 발생하면 해당 이벤트에 대해 정해진 동작을 실행하게 하는 도구라고 할 수 있다.

Git Action 주요 용어

Workflow (워크플로우)

Git Action에서 수행할 작업들을 정의하는 YAML 형식의 파일.

• 각 워크플로우는 하나 이상의 job으로 구성되어 있으며, 이벤트에 따라 실행된다.

• Workflow 파일은 YAML으로 작성되고, Gihub Repository의 .github/workflows 폴더 아래에 저장된다.

  

Event (이벤트):

Git Action workflow가 실행될 때의 트리거.

• Workflow를 실행하는 특정 활동이나 규칙이며, Github에서는 디양한 이벤트를 제공한다.
• 예를 들어, push, pull request, issue 등의 이벤트가 트리거가 될 수 있다.

Job (작업)