GitHub Actions를 이용한 자동화 배포

복준우·2023년 3월 18일

aws s3

목록 보기

3/4

GitHub Actions이란?

GitHub Actions는 GitHub에서 제공하는 클라우드형 CI/CD 툴이다. 코드가 변경되면 자동으로 테스트를 실행하거나, 빌드하고, 배포하는 등의 작업을 수행할 수 있으며 GitHub에서 제공하는 서비스로 GitHub 레파지토리와의 연동이 쉽다.

GitHub Actions의 구성 요소

출처 ) https://docs.github.com/en/actions/learn-github-actions/understanding-github-actions

Workflow
- 작업을 수행하는 데 필요한 모든 정보를 포함하는 자동화된 프로세스이다. 즉, push, pull request open, issue open등과 같은 특정 이벤트에 대해 실행할 수 있는 작업 흐름을 정의하는 것이다.
- YAML 파일에 의해 정의되며 리포지토리의 이벤트에 의해 트리거될 때 실행되거나 수동으로 또는 정의된 일정에 따라 트리거될 수 있다
Event
- 레파지토리에서 발생하는 push, pull request open, issue open등의 특정한 활동을 의미한다.
- GitHub Actions에서는 특정한 Event가 발생했을 시 그에 맞는 CI/CD 파이프라인을 구동하도록 설정할 수 있다.
Jobs
- 하나의 runner에서 실행될 여러 step의 모음을 의미한다.
- step은 실행가능한 하나의 shell script 또는 action을 의미한다.
- job안의 step들은 순차적으로 실행된다.
- 하나의 workflow안에 여러 job들을 설정할 수 있다.
- (기본값)workflow의 job들은 기본적으로 병렬(동시에)로 실행된다.
  - 예시 사진을 보면 job1, job2를 동시에 실행하는 것을 의미
- 일부 job의 경우에는 다른 job에 의존성을 설정해서 다른 job이 완료되고 난 뒤 실행하도록 할 수 있다.
Actions
- GitHub Workflow에서 자주 사용되는 기능들을 모아둔 일종의 커스텀 애플리케이션이다.
- 설정파일에서 use 키워드와 함께 사용할 수 있으며, 예를 들어 브랜치로 체크아웃하고, 환경을 설정하는 등 복잡하지만 자주 사용되는 과정들을 미리 정의해두고 편리하게 활용할 수 있다.
- GitHub Marketplace에서 Action들을 검색하고 활용할 수 있다.
Runner
- workflow를 실행할 서버를 의미합니다. 클라우드형 CI/CD 플랫폼인 GitHub Actions는 직접 컴퓨터를 관리할 필요 없이 가상의 Runner를 통해서 Workflow를 실행시켜준다.
- 현재 GitHub Actions의 Runner는 기본적으로 Node를 탑재하고 있다.

GitHub Actions로 자동화 하기(CD)

지금까지 AWS S3를 통해 정적 웹사이트를 호스팅하는 방법과(S3 버킷에서 기존 자료 삭제 후 재 업로드), AWS CLI를 이용해 명령어로 자동화 배포하는 방법에 대해 알아보았다. 이제 더 나아가 GitHub Actions을 활용하여 CD를 구축하는 방법에 대해 알아보겠다.

master or main 브랜치에 push or Pull Request Merge가 발생하면 workflow 실행
필요한 dependencies들을 설치
build script를 실행
aws s3 버킷에 build한 결과물을 업로드

위의 과정으로 자동화가 진행된다.

GitHub Actions가 구동되는 법

해당 레파지토리/.github/workflows/<액션이름>.yml을 가진 확장자가 있으면 액션으로 인식하고 돌아간다.

로컬에서 작업 중인 프로젝트 폴더에 액션을 만들어준다.

예시코드

.github/workflows/CD.yml

name: CD

on:
  push:
    branches:
      - main
    workflow_dispatch:

jobs:
  cd:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@main
      - run: npm install
      - run: npm run build
      - name: deploy to s3
        uses: jakejarvis/s3-sync-action@master
        with:
          args: --delete
        env:
          AWS_S3_BUCKET: ${{ secrets.AWS_S3_BUCKET }}
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          AWS_REGION: 'ap-northeast-2'
          SOURCE_DIR: 'build'

.github/workflows/CD.yml

name: workflows이름

on: 언제 실행 되는지(push)
  push:
    branches: 어디 브랜치로(-main)
    - main
	workflow_dispatch: 푸시하지 않고 실행 할 수 있게 도와주는 트리거

jobs: 
  cd:
    runs-on: ubuntu-latest //우분트의 최신버전 이용
    steps: 어떤동작
    - uses: actions/checkout@main //main으로 체크아웃
    - run: npm install
    - run: npm run build
    - name: deploy to s3
      uses: jakejarvis/s3-sync-action@master
      with:
        args: --delete //삭제
      env:
        AWS_S3_BUCKET: ${{ secrets.AWS_S3_BUCKET }}
        AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
        AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        AWS_REGION: 'ap-northeast-2' //서울
        SOURCE_DIR: 'build'

uses: actions/checkout@main Github에서 제공하는 Marketplace에서 Checkout Actions을 이용한다.
https://github.com/marketplace/actions/checkout
uses: jakejarvis/s3-sync-action@main s3에 자동으로 배포하기 위해 Marketplace에서 aws s3를 검색해 S3 Sync을 사용한다. https://github.com/marketplace/actions/s3-sync
env 설정 Github Settings에서 Secrets and variables에 시크릿 값을 넣어준다.
- AWS_S3_BUCKET
  - Name : AWS_S3_BUCKET
  - Secret : bucket에서 설정한 이름
- AWS_ACCESS_KEY_ID
  - Name : AWS_S3_BUCKET
  - Secret : 발급 받은 Access Key
- AWS_SECRET_ACCESS_KEY
  - Name : AWS_S3_BUCKET
  - Secret : 발급 받은 Secret Access Key
  
  설정이 완료된 경우

마무리

이제 main 브랜치로 push하면, GitHub Actions를 실행하여 프로젝트를 배포할 수 있다. 프로젝트를 배포하는 과정에서 eslint 라이브러리를 사용하여 경고를 오류로 처리하도록 설정했기 때문에, 액션이 실패한 경험이 있었다. 이렇게 나도 모르게 발생하는 오류를 찾아 수정할 수 있게 되어, 전체 개발 과정에서 더욱 전문적인 시야를 갖출 수 있게 되었다.

프론트엔드 개발자가 배포에 대해 알아야 하는 이유는 다음과 같다

배포 후 발생할 수 있는 버그나 오류를 더 쉽게 식별하고 수정할 수 있다.
배포가 어떤 개념인지, 어떤 식으로 이루어지는지를 모르면 원활하게 문제를 해결하기 어려울 수 있다.
전체 개발 과정을 보는 시야가 넓어지며, 역할이 구체적으로 나뉘어져 있는 개발 팀에서는 서로간의 협업을 위해 배포 과정에 대한 이해가 필요하다.
코드를 작성할 때부터 배포에 대한 고민을 함께 고려할 수 있어 더 나은 코드를 작성할 수 있다.