[Section 4] CI / CD

개발 프로세스

- 요구분석 및 시스템 명세작성
문제분석 단계라고도 하며, 개발할 소프트웨어의 기능과 제약조건, 목표 등을 사용자와 함께 정확히 정의하는 단계

- 설계
설계단계에서는 앞서 정의한 기능을 실제로 수행하기 위한 방법을 논리적으로 결정

- 구현
설계 단계에서 논리적으로 결정한 문제 해결 방법을 프로그래밍언어를 사용하여 실제 프로그램을 작성

- 테스트
개발한 시스템이 요구사항을 만족하는지, 실행 결과가 예상한 결과와 정확하게 맞는지를 검사

- 배포 및 유지보수
배포와 유지보수 단계는 시스템이 인수되고 설치된 후(배포) 일어나는 모든 활동을 지칭

애자일 방식

요구사항이 변하는 것을 전재로 계획에 의존하여 형식적인 절차를 끝까지 따라야 하고 중간에 뒤로 회귀할 수 없는 전통적인 개발 프로세스보다는 훨씬 효율적으로 개발에 착수할 수 있다. 애자일 개발 프로세스를 적절히 사용하면 빠르게 문제를 해결해 하루에도 여러 번의 배포가 가능해진다.

SaaS

클라우드 서비스의 한 방식, 브라우저에 접속하기만 해도 새 버전을 즉시 사용할 수 있는 서비스 방식

---

CI / CD

지속적 통합(Continuous Integration, CI)

CI는 개발자를 위한 자동화 프로세스인 지속적인 통합(Continuous Integration)을 의미한다.
CI를 성공적으로 구현할 경우 여러 명의 개발자가 동시에 애플리케이션 개발과 관련된 코드 작업을 할 경우 서로 충돌할 수 있는 문제를 해결할 수 있다.

• Code: 개발자가 코드를 원격 저장소에 push하는 단계
• Build: 원격 저장소로부터 코드를 가져와 유닛 테스트 후 빌드하는 단계
• Test: 코드 빌드의 결과물이 다른 컴포넌트와 통합 되는지 확인하는 과정

잦은 push로 버그를 일찍 발견할 수 있고 빠른 전달로 지속적인 배포가 가능해진다.

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

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

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

---

배포 자동화

배포 자동화란 한 번의 클릭 혹은 명령어 입력을 통해 전체 배포 과정을 자동으로 진행하는 것을 뜻한다.

CI/CD 파이프라인

수없이 진행되는 배포 과정을 자동화시키는 방법을 구축하게 되는데, 그것을 CI/CD 파이프라인이라고 한다.

• 개발자가 코드를 원격 저장소에 올리면, 그 코드가 빌드 및 테스트와 릴리스를 거쳐 배포 서버로 전달된다.
• 배포 서버에 도달한 빌드된 코드는 애플리케이션 서버로 최종 배포가 완료되고, 그 결과물을 유저가 직접 확인하게 된다.
• 여기서 자동화를 꾀하는 부분은 보통 코드가 빌드되면서 최종적으로 배포가 되는 단계까지이다.
• 이 부분을 지속적인 통합 및 배포를 위하여 일련의 자동화 단계로 만드는데, 이것을 파이프라인을 구축한다고 표현한다.

---

YAML(Yet Another Markup Language)

사람이 읽을 수 있는 데이터 직렬화 언어를 의미
다른 프로그래밍 언어와 함께 사용할 수도 있다. YAML은 그 유연성과 접근성으로 인해 자동화 프로세스를 생성하는 데에도 사용된다.

Github Action

1. AWS accces key, secret key 준비

2. AWS key 깃헙 actions에 등록

![]

1. Setting
2. Security메뉴에서 actions 선택
3. new repository secret 버튼을 클릭하여 키를 생성한다. 키는 총 2개 등록한다.
   • Name에는 키의이름, Secret에 각 키의 이름과 값을 넣고 Add secret 버튼을 클릭한다.

1번에 AWS의 엑세스 키 ID를 값으로 AWS_ACCESS_KEY_ID로,
1번에 AWS의 비밀 엑세스 키를 값으로 AWS_SECRET_ACCESS_KEY라는 이름으로 생성한다.

Github actions AWS키 등록(공식문서)

3. '.github'폴더에 yml파일 작성

등록한 키로 배포할 작업물에 yml파일을 작성하고,
리포지토리에 push 하면 자동으로 빌드 후 S3의 버킷으로 업로드가 된다.
-->
이렇게 자동화하기위해 yml 파일을 작성해주어야한다.

파일 위치: ./.github/workflows/client.yml

✏️ yml

name: 자동으로 처리할 액션의 임의의 이름
on: 언제 이 액션이 실행될지 명시
jobs: 구체적으로 실행할 내용

✅ on

name: client
on:
  push:
  # 이벤트 브랜치
    branches:
      - reference

• 액션이름: client
• on에는 git push시 실행하도록 작성
• 실행할 브랜치:reference

✅ jobs ✅

✅ 모듈 설치

각 스텝을 작성(steps 안에 실행내용)
각 실행 내용의 이름은 - name: <내용>으로 작성

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

• 빌드하기 위한 모듈 설치
  - npm install로 설치하기 위해 run:에 npm install작성
• working-directory에는 배포할 클라이언트의 디렉토리명

✅ build

# Build 단계
  - name: Build
    run: npm run build
    working-directory: ./my-agora-states-client-react

• 작업물을 build하기 위해 npm run build

✅ AWS S3 버전 확인

생략하고 바로 버킷으로 연결 가능

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

• AWS의 버전을 확인하는 단계로 엑세스 키, 시크릿 키가 필요하다.
• env에 해당 키를 입력한다.

✅ 버킷 연결

빌드한 클라이언트를 버킷에 배포하기 위함

  - name: Sync Bucket
    env:
      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://Bucket-name\
        --delete
     working-directory: ./my-agora-states-client-react

aws s3 sync \ #sync냐 cp에 따라 차이가 있다.
--region ap-northeast-2 \ #리전에 대한 부분이다. 여기선 서울이다.
build s3://fe-63-shinnh2-s3 \ # build s3://[버킷 이름]
--delete #sync, cp와 결합하여 다른 명령어를 사용한다.

❖ aws s3 sync와 aws s3 cp
cp: 기존에 똑같은 파일이 있더라도 모든 파일을 복사하여 업로드
sync: 업데이트된 파일만 복사하여 업로드
여기서 --delete 를 사용하면 업로드시 삭제된 파일이 있다면, 버킷에서도 이를 적용하여 해당 파일을 삭제한다.

참고: 🔗 AWS 관련 가이드

배포 완료!