[💻 코드스테이츠 FE 44기][Deploy] CI/CD

✔️ 시작

CI/CD에 대해 알아보고 직접 실습하는 학습을 진행했다.

---

📍 배운 것

✔️ CI/CD

CI(Continuous Integration)

• 개발자를 위한 자동화 프로세스인 지속적인 통합

CI를 성공적으로 구현할 경우 애플리케이션에 대한 새로운 코드 변경 사항이 정기적으로 빌드 및 테스트되어 공유 리포지토리에 통합되기에
여러 명의 개발자가 동시에 애플리케이션 개발과 관련된 코드 작업을 할 경우 서로 충돌할 수 있는 문제를 해결할 수 있다.

CD(Continuous Delivery / Continuous Deployment)

• 지속적인 서비스 제공(Continuous Delivery) 또는 지속적인 배포(Continuous Deployment)를 의미 (두 용어는 상호 교환적으로 사용)
• 두 가지 의미 모두 파이프라인의 추가 단계에 대한 자동화를 뜻하지만 얼마나 많은 자동화가 이루어지고 있는지를 설명하기 위해 별도로 사용되기도 한다.

CI/CD의 단계

Code - Build - Test - Release - Deploy - Operate - Plan

지속적 통합(Continuous Integration, CI)

• 개발자를 위한 자동화 프로세스
• Code - Build - Test 단계에 해당
  - Code : 개발자가 코드를 원격 코드 저장소(github repository 등)에 push하는 단계
  - Build: 원격 코드 저장소로 부터 코드를 가져와 유닛 테스트 후 빌드하는 단계
  - Test: 코드 빌드의 결과물이 다른 컴포넌트와 잘 통합되는지 확인하는 과정

• 버그를 일찍 발견할 수 있다.
• 테스트가 완료된 코드에 대해 빠른 전달과 지속적인 배포가 가능해진다.
• 모든 개발팀이 코드의 변화를 확인할 수 있기에 투명하게 문제점을 파악할 수 있다.
  (잦은 풀 리퀘스트(pull request)와 머지(merge)로 코드를 자주 통합한다.)
• 개발팀은 각자 개발한 코드를 이른 시점에 자주 합치고 테스트 해볼 수 있다.
• 보안 이슈, 에러 등을 쉽게 파악할 수 있어 해당 이슈를 빠르게 개선할 수 있다.
• 코드를 머지하기 전, 이미 빌드 오류나 테스트 오류를 확인해 훨씬 더 효율적인 개발을 할 수 있게 된다.

지속적 배포(Continuous Delivery/Deployment, CD)

• 지속적인 서비스 제공(Continuous Delivery) 및 지속적인 배포(Continuous Deployment)를 의미한다.
  (두 용어는 상호 교환적으로 사용된다.)

• Release - Deploy - Operate 단계에 해당
  - Release: 배포 가능한 소프트웨어 패키지를 작성
  - Deploy: 프로비저닝을 실행하고 서비스를 사용자에게 노출한다.(실질적인 배포)
  - Operate: 서비스 현황을 파악하고 생길 수 있는 문제를 감지

• 코드 변경사항의 병합부터 프로덕션에 적합한 빌드 제공에 이르는 모든 단계

• 테스트 자동화와 코드 배포 자동화가 포함된다.

• 이 프로세스를 완료하면 프로덕션 준비가 완료된 빌드를 코드 리포지토이레 자동으로 배포할 수 있기에 운영팀이 보다 빠르고 손쉽게 애플리케이션을 프로덕션으로 배포할 수 있게 된다.

클라우드 기술 발전과 맞물려 지속적 통합과 지속적 배포가 빠른 속도로 진행되면서 CI/CD를 하나로 묶어서 다루는 경우가 점차 증가하고 있다.

• 요즘은 고객의 피드백을 빨리 받기 위해서라도, 서비스를 중단하지 않기 위해서라도 릴리스만 잘 기록해 두고 바로바로 배포하는 사례가 증가하고 있다.

CI/CD의 영역

CI/CD는 지속적 통합 및 지속적 제공(CD, Continuous Delivery)의 구축 사례만을 지칭할 때도 있고, 지속적 통합, 지속적 제공, 지속적 배포라는 3가지 구축 사례 모두를 의미하는 것일 수도 있다.

"지속적인 서비스 제공"은 때로 지속적인 배포의 과정까지 포함하는 방식으로 사용되기도 한다.

• CI/CD는 파이프라인으로 표현되는 실제 프로세스 말하며, 애플리케이션 개발에 지속적인 자동화 및 지속적인 모니터링을 추가하는 것을 의미
• 용어는 사례별로 CI/CD 파이프라인에 구현된 자동화 수준 정도에 따라 그 의미가 달라진다.

대부분의 기업에서는 CI를 먼저 추가한 다음 클라우드 네이티브 애플리케이션의 일부로서 배포 및 개발 자동화를 구현해 나간다.

배포 자동화

• 한 번의 클릭 혹은 명령어 입력을 통해 전체 배포 과정을 자동으로 진행하는 것
  - 수동적이고 반복적인 배포 과정을 자동화 되기에 시간 절약된다.
  - 휴먼 에러(Human Error)방지한다.
  배포 자동화를 통해 전체 배포 과정을 매번 일관되게 진행하는 구조를 설계해 휴먼 에러 발생 가능성을 낮출 수 있다.

휴먼 에러?
사람이 수동적으로 배포 과정을 진행하는 중에 생기는 실수들

✔️ CI/CD 파이프라인

• 배포 과정을 자동화시키는 방법

CI/CD 파이프라인 구성 요소 및 장점

구성

• 빌드 (소프트웨어 컴파일)
• 테스트 (호환성 및 오류 검사)
• 릴리스 (버전 제어 저장소의 애플리케이션 업데이트)
• 배포 (개발에서 프로덕션 환경으로의 변환)
• 규정 준수 및 유효성 검사

해당 과정은 실무에서 반복적인 프로세스이기 때문에 이부분을 일련의 자동화 단계로 만든다고 볼 수 있다.

구축된 파이프라인은 최신 버전의 소프트웨어 애플리케이션을 업데이트하고 제공하는
일련의 처리 단계에 걸리는 시간을 수동으로 하는 것보다

• 더 빠르고 안정적이며 효과적으로 줄여주고
• CI/CD 인프라와의 호환성과 효율성을 높여준다.

Github Action

• Github가 공식적으로 제공하는 빌드, 테스트 및 배포 파이프라인을 자동화할 수 있는 CI/CD 플랫폼
• 레포지토리에서 Pull Request 나 push 같은 이벤트를 트리거로 GitHub 작업 워크플로우(Workflow)를 구성할 수 있다.

워크플로우 ?

• 하나 이상의 작업이 실행되는 자동화 프로세스
• 각 작업은 자체 가상 머신 또는 컨테이너 내부에서 실행된다.
• .yml (혹은 .yaml ) 파일에 의해 구성된다.
• 테스트, 배포 등 기능에 따라 여러 개의 워크플로우를 만들 수 있다.
• 생성된 워크플로우는 .github/workflows 디렉토리 이하에 위치해야 한다.

공개(public) 레포지토리로 해야 무료로 사용할 수 있다.

✔️ Github Action 실습

배웠던 내용을 토대로 실습을 진행 했다.
초반에 무슨 말인지.. 이해가 가지 않았지만...ㅠ

기존에 있던 레포지토리로 진행을 했다.
git clone 후 YAML 파일에 적힌 명령어를 토대로 Webpack을 이용해 빌드한다.

client.yml 파일을 만들어 주었다.

name: client
on:
  push:
    branches:
      - reference

파일 명과 branch 명을 작성해 주면 되는 듯 싶어 작성해 주었다.

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-react

name은 해당 행동 명칭을 뜻하는 거 같고
run은 해당 행동을 실행하는 코드를 작성해 주면 되는 듯 싶어 작성해 주었다.
working-directory는 실행할 파일 경로인 듯 싶다..

build 부분도 동일하게 작성해 주었다.

AWS로 배포를 하기 때문에

 - name: SHOW AWS CLI VERSION
        run: |
          aws --version

이 부분은 구글링 하니 버전 확인 하는 것이라고 한다.

 env:
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          AWS_EC2_METADATA_DISABLED: true

AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY는 노출 되면 안되는 부분이라
하드 코딩하면 안 된다.

처음에는 환경 변수로 작성하는 줄 알았지만 github에서 저장 할 수 있었다.
⬇️
github actions 시크릿 키 저장 하는 법

run: |
          aws s3 sync \
            --region ap-northeast-2 \
            build s3://fe-119-jieun419-s3 \
            --delete
        working-directory: ./my-agora-states-client-react

구글링해보니
aws s3 sync \ 는 sync, cp에 따라 차이가 있다.
--region ap-northeast-2 \ 리전에 대한 내용이다.
build s3://fe-119-jieun419-s3 \ 해당 부분은 버킷 이름을 작성해 주면 된다.

그리고 성공한 화면 ㅠㅠ 초반에 자꾸 어디가 문제이지? 했었다.
알고 보니 working-directory가 맞지 않았었다.
그부분을 전부 수정해 주니 해결할 수 있었다.

AWS S3에서 확인 했을 때도 잘 나왔다.

---

✏️ 마치며

실습 중 build 까지는 무난하게 잘 넘어 갈 수 있었다.
aws s3 여기 부터 뭔가 경로를 작성해야하는 거 같은데 어떻게 작성해야하는지 감이 잡히지 않아
시간 소비가 꽤 됐었다.

구글링 하다 다른 분이 하셨던 블로그를 보고 참고를 했다.

감사합니다.🙇‍♀️

또한 yml파일을 작성하면서 초반에 이게 무슨 말이지? 싶었지만
앞서 공부했던 내용을 생각해 보면 자동화 배포이기에
해당 명령어와 그 명령어가 실행된 폴더를 지정하는 것 같았다.

실습을 통해 하나씩 이해하게 되는 것 같다.

참고
https://velog.io/@shinnh2/Github-Actions-AWS-S3-yml