CI/CD

1. 전통적인 개발 프로세스 VS 모던 개발 프로세스

	워터폴(전통적)	애자일(모던)
장점	- 프로세스가 길고 순서가 잡혀 있으므로 팀의 규모에 상관 없이 따르기 쉬움 - 개발 주기가 정해져 있으므로 새로운 프로젝트를 안정적으로 시작 가능 - 요구 사항이 확정되어 있으므로 프로젝트를 실행하기 수월하며, 개발 목표를 자주 변경하지 않아도 됨 - 프로젝트의 전 과정에 필요한 예산 및 자원이 초기에 확정되어 예상 결과와 리스크를 통제하기 훨씬 쉬움	- 빠르면서 유연한 개발 과정 - 짧고 반복적인 스프린트로 구성되어 있어 품질에 초점을 맞출 수 있으므로 빠르게 결함을 인지하고 수정 가능 - 스프린트를 통한 짧은 반복 과정으로 개발 과정 중에 신속히 제품 변경 가능
단점	- 개발이 순차적으로 진행되므로 앞 단계가 완성되지 않으면 다음 단계로 넘어갈 수 없어 개발 속도가 느리고 유연성이 떨어짐 - 테스팅 단계에 이르러서 이슈가 발견되는 경우가 왕왕 있음 - 개발 요구 사항이 초기에 확정되므로 범위 변경이 자유롭지 못함	- 스프린트에 대한 경험이 있으며 빠른 반복 작업에 익숙한 스크럼 마스터가 필요함 - 고객이 수많은 변경 사항을 검토해야만 하는 번거로움 발생 - 팀원이 잘 조직되어 있지 않거나 자립성이 떨어지는 경우 애자일론을 채택할 시 문제가 발생

 

2. 지속적 통합(Continuous Integration, CI)

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

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

 

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

 

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

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

지속적 배포의 경우, 코드 변경 사항의 병합부터 프로덕션에 적합한 빌드 제공에 이르는 모든 단계로, 테스트 자동화와 코드 배포 자동화가 포함된다.

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

 

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

4. CI/CD 파이프라인

4-1. 배포 자동화

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

배포 자동화를 통해

수동적이고 반복적인 배포 과정을 자동화함으로써 시간을 절약할 수 있고,
휴먼 에러(Human Error)를 방지할 수 있다.

 

4-2. CI/CD 파이프라인

CI/CD 파이프라인란 배포 과정을 자동화시키는 방법을 구축하는 것이다.

그림에서 자동화를 꾀하는 부분은 보통 코드가 빌드되면서 최종적으로 배포가 되는 단계까지이다. 이 부분을 지속적인 통합 및 배포를 위하여 일련의 자동화 단계로 만드는데, 이것을 파이프라인을 구축한다고 표현한다.

4-3. CI/CD 파이프라인을 구성하는 기본 단계와 수행 작업

1. Source 단계: Source 단계에서는 원격 저장소에 관리되고 있는 소스 코드에 변경 사항이 일어날 경우, 이를 감지하고 다음 단계로 전달하는 작업을 수행한다.
2. Build 단계: Build 단계에서는 Source 단계에서 전달받은 코드를 컴파일, 빌드, 테스트하여 가공한다. 또한 Build 단계를 거쳐 생성된 결과물을 다음 단계로 전달하는 작업을 수행한다.
3. Deploy 단계: Deploy 단계에서는 Build 단계로부터 전달받은 결과물을 실제 서비스에 반영하는 작업을 수행한다.

 

5. Github Action

GitHub Actions는 Github가 공식적으로 제공하는 빌드, 테스트 및 배포 파이프라인을 자동화할 수 있는 CI/CD 플랫폼이다.

 

레포지토리에서 `Pull Request` 나 `push` 같은 이벤트를 트리거로 GitHub 작업 워크플로(Workflow)를 구성할 수 있다. 워크플로는 하나 이상의 작업이 실행되는 자동화 프로세스로, 각 작업은 자체 가상 머신 또는 컨테이너 내부에서 실행된다.

워크플로는 `.yml` (혹은 `.yaml` ) 파일에 의해 구성되며, 테스트, 배포 등 기능에 따라 여러개의 워크플로도 만들 수 있습니다. 생성된 워크플로는 `.github/workflows` 디렉토리 이하에 위치한다.

공개 레포지토리는 무료로 사용 가능하다.

 

5-1. .yml 작성하기

name: Bare Minimum Requirements
# 워크플로우 이름
on: [push, pull_request]
# 어떤 작업때 할 건지
jobs:
  test:
    runs-on: ubuntu-latest
    # 러너 종류:  윈도우 , 맥, 우분투
    steps:
    #실행하는 작업 선택 =>  깃협에 릴리즈된 버전
      - uses: actions/checkout@v3
      # 작업 단계
      - name: Bare Minimum Requirements
      # 노드 버전 세팅하는 부분
        uses: actions/setup-node@v1
        with:
          node-version: '16'
      - run: npm install
      - run: npm test

name: client
on:
  push:
    branches:
      - reference
jobs:
  build:
    runs-on: ubuntu-20.04
    steps:
      - name: Checkout source code.
        uses: actions/checkout@v2
      - name: Install dependencies
      # 자동으로 install
        run: npm install
        working-directory: ./my-agora-states-client
      - name: Build
      # 자동으로 build
        run: npm run build
        working-directory: ./my-agora-states-client
      - name: SHOW AWS CLI VERSION
        run: |
        # aws 버전 확인
          aws --version
      - 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://fe-55-lulu242-s3 \
            --delete
        working-directory: ./my-agora-states-client

작성 시 글자 끝에 띄어쓰기 포함되면 오류날 수 있으므로 주의하기

 

액션을 통해 자동화 해주기 전이라면

`npm install` -> `npm test` -> `npm build` -> s3버킷에 직접 빌드 파일 업로드

과정을 모두 하나씩 해줘야했다. 

 

하지만 깃헙 액션을 사용하면 push 한 번으로 자동으로 진행된다.

 

참고 AWS CLI Command Reference) https://docs.aws.amazon.com/cli/latest/reference/s3/sync.html

---

깃헙 액션 시크릿 정하기

리포지토리 셋팅에서   Secrets and variables 탭의 Actions 탭 선택

New repository secret 클릭해서 시크릿 추가해주기

 

참고 https://docs.github.com/en/actions/security-guides/encrypted-secrets#creating-encrypted-secrets-for-a-repository

Encrypted secrets - GitHub Docs

 

---

마치며..

웹팩 때 사용한 레퍼런스코드 써서 계속 build 를 못 찾겠다고 나오던 것이였다..

새로 파일 받아서 했으면 이렇게 오래 안걸렸을 텐데 ㅜㅜ

 

 

참고) 코드스테이츠 유어클래스