GiitHub Action에서 Firebase Hosting에 자동 디버깅 설치

개시하다
안녕하세요!
최근 GiitHub Actions가 Firebase Hosting에 CI/CD 설치를 실현했기 때문에 메모로 기사를 쓰고 싶습니다.
GiitHub Action이란?
먼저 GiitHub Action이 무엇입니까?
공식 답변은 다음과 같다.(구글 일본어 번역)
GiitHub Actions를 사용하여 창고 내에서 소프트웨어 개발 워크플로우를 자동화하고 사용자 정의하며 실행합니다.작업을 감지, 생성 및 공유하고 CI/CD를 포함한 모든 작업을 수행하며 완전히 사용자 정의된 워크플로우에서 작업을 조합할 수 있습니다.
GitHub Actions
설명한 대로 CI/CD를 구현하는 도구입니다.
다른 circleaci와 Jenkins도 유명하다고 생각해요.
CI/CD도 복습해.
CI(Continuous Integration)
일본어로 번역하면'지속적인 축적'이다.
개발자가 작성한 새 코드와 메인 지점(캐리어)이 빈번하게 통합되는 과정을 말한다.
CI 도구가 등장하기 전에 개발자는 독립적으로 장기적으로 일을 하여 주 지점으로 통합되었다.
작성량이 많은 코드를 주 지점으로 통합하는 것은 어렵고 고장이 났을 때 여러 가지 변경이 뒤섞일 수 있기 때문에 수정에 드는 비용이 커졌다.
따라서 CI 도구는 코드에서 구축에 성공할 때까지 읽는 시간을 단축하기 위해 가져옵니다.
CI 도구를 가져오면 지금까지 사람들이 진행한 테스트와 구축 작업을 자동화할 수 있습니다.
CI 도구는 처음에 작은 단위로 테스트하고 구축하는 검증으로 단위를 확대하는 동시에 여러 차례 검증하고 파이프를 구축한다.
이러한 실시를 통해 오류 피드백에 대한 통지는 더욱 이르고 영향 범위도 최소한으로 제한될 것이다.
CD(Continuous Delivery)
일본어로 번역하면'지속적인 배송'이다.
이는 지속적분(CI) 연장을 통해 새로운 수정이 발표될 수 있음을 입증하는 과정이다.
모든 코드 변경 사항은 구축 및 테스트 후 테스트 환경 또는 디버깅 환경에서 디버깅을 수행하고 시스템 테스트 및 UI 테스트를 수행합니다.
개발자는 준비가 다 되었을 때 마지막 단계로 운용 환경에 대한 업데이트를 승인한다.
이 점은 명시적 승인 없이 자동으로 환경을 적용하는 설계의 "지속적 설계"와는 다릅니다.
따라서 전체 프로세스로서
CI → CD → 공식 프레젠테이션
이런 흐름.
총결산하다
CI/CD에 관해서는 어때요?
한마디로'구축, 테스트, 디자인을 지속적으로 자동화할 수 있는 기능과 수단'이죠.
CI/CD는 핵심 비즈니스에 집중할 수 있습니다.
실제로 GiitHub Action을 Firebase에 연결해서 사용해 봤어요.
전제 조건
· Firebase에 있는 항목의 상태
※ 아이템이 없으면 먼저 아이템을 만듭니다
Firebase 여기 있어요.
· Firebase Hosting 디자인을 할 수 있는 환경이 있다
(Firebase init를 통해 설정됨)
전체 프로세스
①ci로 영패 만들기
② 영패를github에 저장
③main.yml의 CI/CD 코드
라고 3걸음을 내디뎠다.
①ci로 영패 만들기
터미널 또는 전원 케이스에 firebase login:ci 및 명령을 입력하십시오.
이렇게 하면 브라우저는 아래 그림처럼 시작하여 접근을 허용할 수 있다.

로그인이 완료되면 터미널이나 전원 케이스로 돌아가면 토큰이 발행된다.
붉은 줄이 있는 곳은 영패다.

Firebase 토큰의 수령이 완료되었습니다.
이 영패는 잠시 후github에 저장됩니다. 복사하십시오.
② 영패를github에 저장
영패를 얻을 수 있으니 github 창고로 이동해서 영패를 보관하세요.
아래 그림과 같다
Settings > secrets > New repository secret
구문을 사용합니다.

아래 그림 페이지로 날아갈 것 같아서 영패를 여기에 저장합니다.
Name은 무엇이든 좋습니다.(Firebase Token)에 등록했습니다.
이전에 저장한 토큰을 Value 창에 직접 붙여 넣습니다.

붙여넣기가 완료되면 Add secret 버튼을 누르면 저장이 완료됩니다.
이렇게 되면 영패 보존이 완료되어 마지막 단계로 돌아갑니다.
③main.yml의 CI/CD 코드
그 다음에yml 파일을 가지고 놀아요.
새 디렉터리를 만드십시오. 아래와 같습니다.
.github/> workflows/> main.yml
디렉토리 구조
디렉토리 구조

.
├── .firebase/
├── .github/
│   └── workflows/
│       └── main.yml
├── src/
├── firebase.json
└── package-json

이렇게 구성이 되어 있습니다.
주로 github의 부하를 괴롭혔다main.yml.main.yml 문서의 내용은 다음과 같다.
제가 하나하나 설명해 드릴 테니 먼저 복사해 주세요.
main.yml

name: CI

on: [push]

jobs:
    FrontDeploy:
        name: FrontDeploy
        runs-on: ubuntu-latest
        steps:
            - name: Checkout Repo
              uses: actions/checkout@v2
            - name: setup Node
              uses: actions/setup-node@v2
              with:
                  node-version: 14.x
                  registry-url: "https://registry.npmjs.org"
            - name: Install Dependencies
              run: yarn
            - name: Build
              run: |
                  npm install
                  npm install -g firebase-tools
            - name: deploy to Firebase Hosting
              run: |
                  firebase deploy --token $FIREBASE_TOKEN
              env:
                  FIREBASE_TOKEN: ${{ secrets.FIREBASE_TOKEN }}

name
워크플로우의 이름을 설정할 수 있습니다.
여러 개의 작업 절차를 만들 수 있기 때문에 용도에 따라 name을 변경하는 것을 추천합니다.
on
뭘 촉발할지 확실해.
이번에 [push]로 설정했기 때문에 github에서 Push를 하면 실행할 수 있습니다.
그 외에도 Pull Request 등이 있습니다.
jobs
모든 작업은 가상 환경의 새로운 실례에서 실행된다.
잡스로 나뉘어 병행 집행과 순서대로 집행할 수 있다.
Step
Job이 수행한 프로세스의 모음입니다.
run
실행할 명령을 기록하다.
여기서는 firebase deploy --token $FIREBASE_TOKEN를 통해 CI/CD를 사용할 수 있습니다.name:build에서 실행된 곳은 디버깅 작업이다.
npm에 패키지를 설치하여 Firebase-tools를 사용할 수 있습니다.
실제로 한번 써볼게요.
마스터 or main 지점에서push를 시도해 보세요. 아래 그림처럼 성공하면 depro가 완성됩니다.

최후
어때?
개인적인 소감으로는 의외로 기릿허브 액션스가 쉽게 활용할 수 있다.
이번에는 최소한의 설정일 뿐이니 스스로 맞춤 제작하면 재미있을 것 같다.
그럼 감사합니다.
참고 자료