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 라이브러리를 사용하여 경고를 오류로 처리하도록 설정했기 때문에, 액션이 실패한 경험이 있었다. 이렇게 나도 모르게 발생하는 오류를 찾아 수정할 수 있게 되어, 전체 개발 과정에서 더욱 전문적인 시야를 갖출 수 있게 되었다.
프론트엔드 개발자가 배포에 대해 알아야 하는 이유는 다음과 같다
- 배포 후 발생할 수 있는 버그나 오류를 더 쉽게 식별하고 수정할 수 있다.
- 배포가 어떤 개념인지, 어떤 식으로 이루어지는지를 모르면 원활하게 문제를 해결하기 어려울 수 있다.
- 전체 개발 과정을 보는 시야가 넓어지며, 역할이 구체적으로 나뉘어져 있는 개발 팀에서는 서로간의 협업을 위해 배포 과정에 대한 이해가 필요하다.
- 코드를 작성할 때부터 배포에 대한 고민을 함께 고려할 수 있어 더 나은 코드를 작성할 수 있다.
출처
https://docs.github.com/en/actions
원티드 프리온보딩 9차 강의
