Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[ALL] 프론트엔드 배포 자동화 yml 파일 생성 #212

Merged
merged 1 commit into from
Aug 13, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
92 changes: 92 additions & 0 deletions .github/workflows/frontend-cd.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,92 @@
name: 모모 프론트엔드 배포 자동화 워크플로우

on:
push:
branches: ["develop"]

permissions:
checks: write

jobs:
detect-changes:
runs-on: ubuntu-latest
permissions:
pull-requests: read
outputs:
backend: ${{ steps.filter.outputs.backend }}
frontend: ${{ steps.filter.outputs.frontend }}
steps:
- uses: actions/checkout@v4 # Push 이벤트이기 때문에 checkout 해야 함
with:
ref: develop
- uses: dorny/paths-filter@v3
id: filter
with:
base: "develop" # 해당 브랜치의 last commit과 변경점 비교
filters: |
backend:
- 'backend/**'
frontend:
- 'frontend/**'

fe-build:
needs: detect-changes # jobs들은 병렬로 실행됨, needs 키워드를 사용해서 특정 job이 완료(성공)면 실행하도록 설정
if: ${{ needs.detect-changes.outputs.frontend == 'true' }}
runs-on: ubuntu-latest
defaults:
run:
shell: bash
working-directory: ./frontend

steps:
- name: 모모 레파지토리의 코드를 가져와요 :)
uses: actions/checkout@v4

- name: 노드 버젼을 설정해요 :)
uses: actions/setup-node@v4
with:
node-version: "lts/*"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[Q]

나중에 버전이 업데이트 되어도 우리 프로젝트에 영향이 갈 일이 없을까요?
버전을 명시하기 vs lts 버전을 유지하기 어떤 부분이 나을까요? 해리의 의견이 궁금해요!


- name: 이전 의존성을 저장해둔게 있나~? 확인해요 :)
id: cache
uses: actions/cache@v4
with:
path: "frontend/node_modules"
key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
restore-keys: |
${{ runner.os }}-node-
${{ runner.os }}

- name: package-lock.json을 활용해서 의존성을 깨끗하게 설치해요 :)
if: steps.cache.outputs.cache-hit != 'true'
run: npm ci

- name: .env 파일을 생성해요 :)
run: |
echo "${{ secrets.MOMO_FE_ENV }}" >> .env

- name: 프론트엔드 리소스를 빌드해요 :)
run: npm run build

- name: 프론트엔드 리소스 결과물을 깃허브 레파지토리 artifacts로 업로드해요
uses: actions/upload-artifact@v4
with:
name: momoResources
path: frontend/dist

deploy:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

백엔드 워크플로우 네이밍과 같이 작업 이름을 fe-deploy로 짓는 것은 어떨까요?

needs: fe-build
runs-on: self-hosted
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

배포 워크플로우시에 self-hosted를 사용하는 이유가 궁금해요!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CloudFront 배포 특성 상 S3버킷에 빌드된 결과물(html, js, asset 등)을 업로드하고 CF에서 해당 S3를 '원본(공식번역이 이렇긴한데.. Origin 입니다)' 설정하여 라우팅 해 주는데, IAM 키를 직접 발급할 수 없어서 외부에서 S3 버킷에 접근이 불가능합니다.

저희가 사용하는 EC2에는 IAM Role이 설정돼 있어서 별다른 인증 작업 없이 aws s3 커멘드만으로 버킷 접근이 가능하구요.

Copy link
Contributor

@seunghye218 seunghye218 Aug 12, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

저희 상황에서 CloudFront에 접근하기 위해 사용하는 것이었네요. 좋습니다👍👍

env:
CLOUDFRONT_DISTRIBUTION_ID: ${{ secrets.CLOUDFRONT_DISTRIBUTION_ID}}
steps:
- name: 모모 깃허브 레파지토리 artifacts로 부터 빌드 결과물을 다운받아요 :)
uses: actions/download-artifact@v4
with:
name: momoResources
path: ./frontend/dist
- name: aws에 배포하고 cloudfront 캐싱을 무효화해요
working-directory: ./frontend/dist/
run: |
aws s3 sync ./ s3://techcourse-project-2024/momo --delete
aws cloudfront create-invalidation --distribution-id "$CLOUDFRONT_DISTRIBUTION_ID" --paths "/*"