Github Actions - React 프로젝트를 Firebase에 Deploy 하기

Actions 마지막 포스트로 React 프로젝트를 Firebase에 Deploy 하는 글을 써보도록 하겠습니다. 우리는 지난 포스트에서 YAML 파일을 가지고 간단한 Workflow와 Matrix와 Secrets 등의 환경 변수까지를 다뤄봤습니다.

 

이번 글에서는 기본적으로 Google Firebase에 대한 기본적인 지식이 있는 상태에서 진행을 하도록 하겠습니다. Firebase의 처음부터 시작하게 되면 글이 길어지기 때문에, 간단하게 요점만 짚고 넘어가기 위해서 Firebase의 기본 환경이 이미 구축된 상태에서 진행하도록 하겠습니다.

 

 

Generate and Register Firebase Token

배포 도구로 Google Firebase에서 공식적으로 제공하는 firebase-tools를 한 번 사용해보도록 하겠습니다. 이 툴은 Node.js 기반으로 되어 있어서 Node Package Manager (이하 NPM)을 이용해 설치하면 됩니다.

$ npm install -g firebase-tools

혹은 Yarn을 사용하실 분이시라면, 아래의 명령어도 괜찮겠죠?

$ yarn global add firebase-tools

이렇게 firebase-tools 설치가 끝났으면 firebase 배포 명령어를 사용하실 수 있습니다.

자 여기서 우리가 필요한 것은 바로 Firebase 배포시 사용할 인증 Token입니다. 이 Token은 여러분의 배포 환경이라는 표식의 인증키인데요. 이 키가 없으면 Firebase가 어디로 배포할지를 알 수가 없겠죠? 따라서 이를 생성해줘야 합니다.

$ firebase login:ci

firebase login 명령어에 ci의 argument를 붙이게 되면, 웹 페이지가 나와 자신의 Google 계정으로 로그인하시면 됩니다. 로그인이 성공적으로 완료되면, 아래와 같이 터미널에 자신의 Token이 표시가 됩니다.

 

자신의 Token이 생성이 되었으면 이제 이 Token을 Repository의 Secrets에 추가해주면 됩니다.

 

Repository의 Settings 항목에 가시면, Secrets 항목이 생겨져 있는 것을 알 수 있습니다. Add a new secret 버튼을 클릭하여 FIREBASE_TOKEN이라는 이름으로 Secrets를 생성하시면 됩니다..

 

 

 

Create Workflow

자 이제 워크플로우를 만들어보도록 하죠. 여기서 저희가 만들 워크플로우는 2개입니다. React 프로젝트는 웹 프로젝트이기 때문에 빌드하고 테스트하는 과정이 1개 있어야 하고, 그리고 마지막으로 빌드와 테스트가 성공적으로 끝났다면 실제 클라우드나 On-Premise 환경에 배포하는 것까지가 최종 개발 및 테스트 프로세스가 되겠습니다.

 

그렇다면 어떻게 구성하면 될까요? master 브랜치를 Production하는 브랜치라고 가정하고 그 외의 브랜치를 Develop 하는 브랜치라고 간단하게 구성한다면, master에 push 되는 단계에서 Deploy를 수행하면 되고, 그 외의 브랜치에서는 Push하는 이벤트를 허용하 되, master 브랜치로 PR을 요구한다면, 그 때 테스트 환경을 구축하도록 만들면 되겠습니다.

 

Firebase Deployment Flow

다이어그램으로 표시하면 대충 이렇게 될 것 같네요. 다른 브랜치를 만들고 PR을 올리게 되면, Github에서 Actions에게 빌드 이벤트를 보내게 되구요. 그 상태를 Github에서 받고 Merge가 이루어지면 Firebase로 Deploy 하는 형태입니다.

 

그럼 첫 번째 Workflow를 만들어보죠.

name: React Build

on: [ pull_request ]

jobs:
  build:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [10.x]

    steps:
      - name: Set up Node.js ${{ matrix.node-version }} 
        uses: actions/setup-node@v1
        with:
          node-version: ${{ matrix.node-version }}
      - uses: actions/checkout@v1
      - name: npm install, build
        run: |
          npm install
          npm run build --if-present

1번째 Workflow는 PR 이벤트가 발생했을 때 이뤄지는 워크플로우입니다. on 클래스에 pull_request 이벤트만을 주어줬기 때문에 어떤 브랜치에서든지 PR이 발생하면 이 워크플로우가 작동합니다. 

name: React Deploy

on:
  push: 
    branches:
      - master

jobs:
  build_and_deploy:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [10.x]

    steps:
      - name: Set up Node.js ${{ matrix.node-version }} 
        uses: actions/setup-node@v1
        with:
          node-version: ${{ matrix.node-version }}
      - uses: actions/checkout@v1
      - name: npm install, build
        run: |
          npm install
          npm run build --if-present 
      - name: Deploy Firebase
      	env:
          FIREBASE_TOKEN: ${{ secrets.FIREBASE_TOKEN }}
        run: |
          npm install firebase-tools
          firebase deploy --token $FIREBASE_TOKEN --non-interactive

2번째 Workflow는 master에 Push 했을 때 이뤄지는 워크플로우지요. 사실 이렇게 하면 그냥 master에 Push했을 때도 이 배포가 진행되기 때문에 실제 사용할 때는 master branch의 권한을 강화하는 것이 좋겠네요.

 

마지막으로 firebase deploy 명령어를 사용해서 아까 저장한 FIREBASE_TOKEN을 불러주시면 되겠습니다.

 

 

Results

그럼 이제 PR을 한 번 올려볼까요? 

PR을 올리면 이렇게 첫 번째 Workflow의 이름이 나타나고, Actions에서 빌드 환경을 생성한 다음, 빌드가 이루어지게 됩니다. 

빌드가 성공적으로 완료되면 초록색 체크 표시를, 실패하면 빨간색의 X 표시를 건내게 됩니다.

마지막으로 Merge를 진행하면 master 브랜치에 Push 이벤트가 발생하면서 아까 만들었더 2번째 워크플로우가 실행됩니다. 2번쨰 워크플로우에는 Firebase로 Deploy까지가 담겨져 있었죠?

Master 브랜치에 Merge를 시도하면 새로운 커밋이 만들어지게 됩니다. Actions에 가보시게 되면, PR #2번에 대한 2번째 워크플로우가 실행되고 있음을 보여줍니다. 

 

 

마치며...

여기까지 Github Actions에 대한 글에 적어봤습니다. Github Actions는 아직 공식적으로 Github에서 제공하는 기능은 아닙니다. 현재는 Beta로 제공하고 있고, 신청자 중 메일을 받은 사람에 대해서만 사용할 수 있는 기능입니다.

 

첫 글에서도 말씀드렸었지만 Github Actions가 Travis CI를 대체할 수 있기에는 Travis CI 본연체를 사용하고 있기 때문에 사실상 대체라고 보기에는 어렵고 Collaboration된 형태라고 보면 쉬울 듯합니다. 추가로 여기에 Linux / OS X 환경만 지원했던 Travis CI에 Windows 환경까지 추가되었기 때문에 콜라보가 오히려 더 어울리는 형태라고 할 수 있을 것 같습니다.

 

본래 Github Actions는 HCL로 작성하여 Visual Editor가 제공된 바 있었습니다. 하지만 HCL은 2019년 9월 30일부로 완전히 제거되어 앞으로는 계속 YAML만 사용할 것이라고 합니다.

Github Actions

GitHub Actions

간단한 후기를 작성해보자면, Github Actions에서는 Github의 각종 이벤트(Push, Pull-request 등)을 직접 접근할 수 있기 때문에 더 강화된 Ci/CD 환경을 만들 수 있다는 것이 장점입니다. 또, 각 빌드 상태를 Success, Failure 등의 함수로 지원하여 실패했을 경우에는 사용자 정의의 Actions를 실행할 수 있어 보다 다양한 애플리케이션을 이용해서 만들었던 PR 테스트 환경을 Actions 한 개로도 충분히 가능할 수 있다는 것이 돋보였습니다.

 

Docker와의 직접 연동이 가능하다는 점이 있습니다. 이 포스트에서는 다루지 않았지만 실제로 Github Actions는 Docker와 아주 친근하게 적용이 가능합니다. Docker Hub와 같은 외부 Docker 레포지터리에서 쉽게 이미지를 다운로드 받을 수 있고, 또 파라미터도 쉽게 사용할 수 있습니다.