CI/CD github-action을 통한 client 배포

돌리의 하루·2023년 4월 3일
0

🍊CI/CD

CI/CD는 애플리케이션 개발 단계를 자동화하여 애플리케이션을 보다 짧은 주기로 고객에게 제공하는 방법

CI

개발자를 위한 자동화 프로세스인 지속적인 통합(Continuous Integration)을 의미한다.

CD

지속적인 서비스 제공(Continuous Delivery) 또는 지속적인 배포(Continuous Deployment)를 의미한다.

그렇다면 지속적인 배포지속적인 제공은 무엇일까?

지속적인 제공

개발자들이 애플리케이션에 적용한 변경 사항이 버그 테스트를 거쳐 리포지토리에 자동으로 업로드 되는 것으로, 운영팀은 이 리포지토리에서 애플리케이션을 실시간 프로덕션 환경으로 배포할 수 있다.

지속적인 배포

개발자의 변경 사항을 리포지토리에서 고객이 사용 가능한 프로덕션 환경까지 자동으로 릴리스 하는 것을 의미한다. 이는 애플리케이션 제공 속도를 저해하는 수동 프로세스로 인한 운영팀의 프로세스 과부하 문제를 해결한다.


*** 중간에 궁금해서 찾아본 배포 영단어의 차이

release, deployment, distribution

  • release는 같은 제품을 새롭게 만드는 것이다
  • distribute는 제품을 사용자들이 사용할 수 있게 배포하는것이다
  • deploy는 프로그램을 서버와 같은 곳에 설치하여 작동가능하게 만드는 것이다

SaaS

클라우드 서비스의 한 방식으로, 브라우저에 접속하기만 해도 새 버전을 즉시 사용할 수 있는 서비스 방식입니다. 애플리케이션부터 서버, 가상화, 스토리지, 네트워킹까지 전부 공급자 쪽에서 관리하기 때문에 고객이 제어하거나 관리할 부분이 거의 없게 됩니다. 따라서 사용자 업데이트에 대한 걱정에서 벗어나며, 하루에 여러 번의 배포도 가능합니다. 또한 빠른 배포 속도도 보장 받을 수 있습니다.

YAML 과 JSON

//yaml 예제
name: Bare Minimum Requirements
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Bare Minimum Requirements
        uses: actions/setup-node@v1
        with:
          node-version: '16'
      - run: npm install
      - run: npm test
//json예제
{
  "squadName": "Super hero squad",
  "homeTown": "Metro City",
  "formed": 2016,
  "secretBase": "Super tower",
  "active": true,
  "members": [
    {
      "name": "Molecule Man",
      "age": 29,
      "secretIdentity": "Dan Jukes",
      "powers": [
        "Radiation resistance",
        "Turning tiny",
        "Radiation blast"
      ]
    }
  ]
}

위의 두 언어를 봤을때, 계층 구조를 가지는것은 동일합니다.

그러나 YAML 파일은 "" (큰따옴표, double quotation marks) 없이 문자열 작성이 가능해, 설정을 위한 스펙이나 프로퍼티 값 등이 JSON 파일에 비해 한 눈에 들어온다는 점입니다. 또한 JSON 파일처럼 {} 형태로 감싸줄 필요도 없기 때문에 스코프의 압박(잘못 쓰면 일일이 어디가 처음이고 끝인지 찾아야 하는 등)에서 벗어날 수도 있습니다.

게다가 YAML 파일은 JSON 파일과 다르게 주석을 작성할 수 있다는 점도 굉장한 이점으로 작용합니다. JSON 파일은 주석을 작성할 수 없기 때문에 해당 파일 하나만 두고 커뮤니케이션 하기가 까다롭지만, YAML 파일은 애초에 파일 내에 주석을 작성할 수 있기 때문에 커뮤니케이션 하기가 훨씬 수월합니다.

그리고 YAML은 JSON의 상위 호환 격이므로, 기존 json문서를 그대로 yaml파일로 사용하거나 원하는 부분만 손볼 수 있습니다. 반대로 yaml을 json으로 변환해 사용할 수도 있다는 점이 장점으로 작용합니다.

Github Action을 통한 react 배포

크게 3단계로 나누어지는 aws을 통한 배포 단계가 있다.

1.Source: Github reference 브랜치에 코드가 커밋되면
2.Build: github acitons의 YAML 파일에 적힌 명령어를 토대로 Webpack을 이용해 빌드를 하고
3.Deploy: github acitons의 YAML 파일에 적힌 명령어를 토대로 s3로 빌드 결과를 업로드합니다.

우선, 실습 전에 튜토리얼로 새로운 레포지토리를 만들고, 거기에 서버 레퍼런스를 클론 받았다.

git clone git@github.com:codestates-seb/fe-sprint-my-agora-states-server-reference.git

클론 받은 곳에서 내가 만든 새로운 레포지토리를 원격 레포지토리로 등록했다.

git remote add myRepo git@github.com:{내 아이디}/{새로운 리포지토리 이름}.git

이후 기존 레퍼런스 코드를 새로운 레포지토리로 push 했다.

git push myRepo reference

푸시하고 나서 github action을 보면, 활성화 된 모습을 확인할 수 있다.

Github Action은 Github의 특정 이벤트에 맞게 다양한 작업을 시킬 수 있는 CI/CD 플렛폼입니다. EC2와 같은 하나의 가상 인스턴스를 실행시켜서 원하는 작업을 시킬 수 있습니다. 그런데, 리포지토리를 push하기만 했는데, 왜 작동했을까요? ./.github/workflows/pullRequest.yml 파일을 읽어봅시다. 언제 어떤 job을 할지 명시되어 있습니다.

//./.github/workflows/pullRequest.yml
name: Bare Minimum Requirements

# 언제 job을 작동시킬지
on: [push, pull_request]

# 어떤 job을 할지
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Bare Minimum Requirements
        uses: actions/setup-node@v1
        with:
          node-version: '16'
      - run: npm install
      - run: npm test
  • npm install은 빌드를 위한 준비과정으로 볼 수 있습니다. Node.js로 만든 서버 애플리케이션은 npm으로 관련 오픈소스를 모두 깔끔하게 설치해야 작동하기 때문입니다.

  • npm test는 유닛 테스트 과정입니다. 작성한 코드가 요구사항 충족을 위한 최소한의 조건을 만족했는지 확인하고 있습니다.

이제, 발급받은 accesskey와 secretkey를 github-secrets and variables-actions- New repository secret을 누른 후 각각 AWS_ACCESS_KEY_ID,AWS_SECRET_ACCESS_KEY를 설정해준다. 노출되면 안되기에 절대 yaml파일에 하드코딩해서는 안된다.

/.github/workflows/client.yml
name: client //실행할 액션이름
on:
  push:
    branches:
      - reference //branch에 push 될 때 실행된다
jobs:
  build:
    runs-on: ubuntu-20.04
    steps: //인스턴스에 실행할 각 절차를 나열
      - name: Checkout source code.
        uses: actions/checkout@v2
      - name: Install dependencies
        run: npm install
        working-directory: ./my-agora-states-client
      - name: Build
        run: npm run build
        working-directory: ./my-agora-states-client
      - name: SHOW AWS CLI VERSION // 기본적으로 설치된 flows CLI버전
        run: | //이 부분은 줄바꿈이다
          aws --version // AWS의 버전 확인하기
      - name: Sync Bucket // AWS S3버킷에 build 파일을 업로드한다
        env: //repository의 secret을 이용해서 지정한 부분
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          AWS_EC2_METADATA_DISABLED: true
        run: |
          aws s3 sync \
            --region ap-northeast-2 \   //이 부분은 올라갈 파일의 경로
            build s3://fe-50-yeomdogyeong-s3 \   //이 부분은 버킷의 경로
            --delete
        working-directory: ./my-agora-states-client

git status로 확인해준 후, git add . 와 commit 메세지까지 남겨준 후에

git push myRepo reference

로 푸쉬해주었다.

잘 빌드 되었다! 야호 🐹🍭

++ build가 안되서 열심히 수정한 흔적을 남기고 떠난다..총총

profile
진화중인 돌리입니다 :>

0개의 댓글