저번 디자인시스템 프로젝트를 통해 처음 github actions를 접한 후, 배포 자동화의 맛을 제대로 알아버린 나는 이번 WILIM 프로젝트에서도 이를 꼭 적용하고자 했다.
현재 프로젝트의 프론트엔드 코드는 Netlify서비스를 이용하여 upstream main 브랜치에 push됨과 동시에 배포가 자동적으로 이루어지지만, 백엔드는 수동으로 배포를 진행하고 있었다. 나는 이 과정이 너무 귀찮기도 할 뿐더러 백엔드 팀원 분들이 개발서버에서만 작성하고 확인한 코드를 더 빈도 높게 배포하여 실제 서버에서 어떻게 확인되는지 빠르게 테스트할 수 있도록 돕고자 하였다.
기존에 수동 배포를 진행할 때는 큰 단위의 기능 개발 후에만 배포를 진행했기에 중간중간 실제 서버에서 잘 돌아가는지 알 수 없었다. 이는 개발 경험(DX)감소와 개발 시간 연장을 불러왔기에 빠른 배포 자동화 파이프라인 구축은 필수적이었다.
실제 내가 수동으로 배포하는 과정은 다음과 같았다.
-
@babel/cli를 이용하여 es6문법으로 작성된 코드를 es5 문법으로 컴파일
(node는 es6를 이해하지 못한다). -
컴파일된 파일이 담긴 폴더를 package.json과 함께 압축.
-
압축 파일을 AWS 콘솔에 접속하여 업로드.
이 과정을 매번 반복하기란 쉬운 일이 아니었고, 수동으로는 자주 업로드하지 못했던 만큼 백엔드 개발자분들도 실제 서버 위에서 코드 작동을 자주 테스트하기 어려웠을것이다.
그래서 사용한 것이 github actions였고, 다행히 github marketplace에 Beanstalk 배포 자동화를 위한 Beanstalk Deploy라는 actions 패키지가 존재했다.
해당 패키지를 사용해서 아주 쉽게 yml파일을 작성할 수 있었고, 작성된 파일의 내용은 다음과 같다.
name: deploy-to-EB
on:
push:
branches:
- main # 배포를 트리거할 브랜치를 명시해준다.
workflow_dispatch:
jobs:
build:
runs-on: ubuntu-latest # action이 구동될 OS 환경을 세팅해준다.
steps:
- name: Checkout
uses: actions/checkout@v2
- name: Set up Node # action이 구동될 Node 환경을 세팅해준다.
uses: actions/setup-node@v3
with:
node-version: 16.x
- name: npm install # package.json에 있는 의존성 파일들을 설치해준다.
working-directory: ./WEB(BE)
run: npm install
- name: npm compile with babel # babel을 이용하여 es5로의 컴파일을 진행해준다.
working-directory: ./WEB(BE)
run: npm run compile # npx babel src --out-dir dist(실제 실행되는 명령어)
- name: make zip file # 압축 파일을 만들어준다.
working-directory: ./WEB(BE)
run: zip -r app.zip package.json ./dist
- name: Deploy to EB # Elastic Beanstalk으로 배포를 진행한다.
uses: einaregilsson/beanstalk-deploy@v20
with:
aws_access_key: ${{ secrets.AWS_ACCESS_KEY_ID }}
aws_secret_key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
application_name: wilim-back
environment_name: Wilimback-env
version_label: ${{ github.run_number }}
use_existing_version_if_available: true
region: ap-northeast-2
deployment_package: ./WEB(BE)/app.zip위의 과정에서 AWS_ACCESS_KEY_ID와 AWS_SECRET_ACCESS_KEY는 Actions Secret에 저장하였는데, upstream의 코드는 해커톤 주최측의 organization에 포함된 레포지토리에 존재했으므로 혹시라도 key가 노출될 위험이 있다고 생각했다.
그래서 Beanstalk에 관한 권한만을 가지는 IAM User를 추가하여 진행했다.
이번 배포 파이프라인을 구축하면서 알게된 것은 각 job의 step은 최대한 구체적으로 적어야 디버깅하기 편하고, 에러가 발생한 부분을 확인하기 좋다는 것이다.
실제 파이프라인을 구축하는 과정에서 실패를 몇 번 거쳤는데, 기존에 step을 여러 단계로 나눠두다보니 어느 과정에서 문제가 발생했는지 확인하기 매우 좋았다.
다만 아쉬웠던 것은 테스트코드도 포함하여 테스트 자동화도 구현하고 싶었지만, 주어진 시간이 많지 않아 그것은 하지 못했다.
이번 경험을 잘 살려 다음에도 좋은 CI/CD 파이프라인을 구축해보자.
참고한 사이트는 다음과 같다.
9분 59초 만에 Github Action + AWS Elastic Beanstalk로 TS 프로젝트 CI/CD 파이프라인 구축하기
Github Action & AWS Beanstalk 배포하기
