[230605] CI/CD + 깃 액션

개발 및 유지보수 단계

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

 

   Chapter 1 .  CI/CD

CI/CD 는 파이프라인으로 표현되는 실제 프로세스를 의미하고 애플리케이션 개발에 지속적인 자동화 및 지속적인 모니터링을 추가하는 것을 의미합니다. 다만 이 용어들은 사례별로 CI/CD파이프라인에 구현된 자동화 수준 정도에 따라 그 의미가 달라집니다만 대부분의 기업에서는  " CI " 먼저 추가 후 클라우드 네이티브 애플리케이션의 일부로서 "CD " 배포 및 개발 자동화를 구현해 나갑니다. 

 

 

 

[1] CI : 개발자를 위한 자동화 프로레스인 지속적인 통합

* Continuous Integration

* 개발자를 위한 자동화 프로세스

 

 

애플리케이션에 대한 새로운 코드 변경 사항이 정기적으로 빌드 및 테스트되어 공유 리포지토리에 통합됩니다. 

여러 명의 개발자가 동시에 애플리케이션 개발과 관련된 코드 작업을 할 경우 서로 충돌 할 수 있는 문제를 해결 할 수 있습니다. 

 

- Code : 개발자가 코드를 원격 저장소에 push 하는 단계

- Build  : 원격 저장소로부터 코드를 가져와 유닛 테스트 후 빌드 하는 단계

- Test   : 빌드 결과물이 다른 컴포넌트와 잘 통합되는지 확인하는 단계

 

이러한 지속적인 통합 과정을 통해 개발자는 버그를 일찍 발견할 수 있고 테스가 완료된 코드에 대해서는 빠른 전달과 지속적인 배포가 가능해진다는 장점이 있습니다. (잦은  PR과 Merge)

 

 

 

[2] CD : 지속적인 서비스 제공 및 지속적인 배포

* Continuous Delivery / Continuous Deployment

 

 

*파이프라인의 추가 단계에 대한 자동화를 뜻하지만 때로는 얼마나 많은 자동화가 이루어지고 있는지를 설명하기 위해 별도로 사용되기도 합니다. 

 

- Release : 배포 가능한 소프트웨어 패키지를 작성하는 단계

- Deploy.  : 프로비저닝을 실행하고 서비스를 사용자에게 노출하는 단계 [ 실질적 배포 부분 ]

- Operate : 서비스 현황을 파악하고 생길 수 있는 문제를 감지

 

프로덕션 준비가 완료된 빌드를 코드 리포지토리에 자동으로 배포할 수 있기 때문에 운영팀이 보다 빠르고 쉽게 애플리케이션을 프로덕션으로 배포할 수 있게 됩니다. 최근에는 클라우드 기술 발전과 맞물려 지속적 통합과 지속적 배포가 빠른 속도로 진행되면서 CI/CD를 하나로 묶어서 다루는 경우가 점차 증가하고 있습니다. 

 

 

* CI/CD 파이프라인

하루에 여러 번 배포가 가능해졌는데 배포하기 위한 과정을 매번 반복한다면 시간도 오래 걸리고 과정도 귀찮을 것 입니다. 이러한 배포 과정을 자동화 시키는 방법이 바로 CI/CD파이프라인 입니다. 

1. 개발자가 원격 저장소에 코드를 올린다.
***
2. 해당 코드가 빌드 및 테스트와 릴리스를 거쳐 배포 서버로 전달 된다. 
3. 배포 서버에서 빌드된 코드는 애플리케이션 서버로 최종 배포가 완료 된다. 
***
4. 유저가 결과물을 확인 할 수 있다. 


CI/CD파이프라인 구성 요소 와 장점은 다음과 같습니다. 
- 빌드(소프트웨어 컴파일) / 테스트 ( 호환성 및 오류 검사) / 릴리스 ( 버전 제어 저장소의 애플리케이션 업데이트) 
- 배포(개발에서 프로덕션 환경으로의 변환) / 규정 준수 및 유효성 검사 

이렇게 구축된 파이프라인은 최신 버전의 소프트웨어 애플리케이션을 업데이트하고 제공하려는 일련의 처리 단계에 걸리는 시간을 수동으로 하는 것보다 더 빠르고 안정적이며(휴먼 에러 감소), CI/CD 인프라와의 호환성과 효율성을 높여준다는 장점이 있습니다. 

 

 

 

 

 

 

 

   Chapter 2 .  Git Action

 

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

 

 

 

PR 이나 Push 같은 이벤트를 트리거로 GitHub작업 워크플로우를 구성할 수 있습니다. "워크플로우"는  . yml 파일에 의해 구성되며, 테스트, 배포 등 기능에 따라 여러 개의 워크플로우로도 만들 수 있습니다. .github/workflows디렉토리 이하에 위치합니다. 

 

# 깃허브 Actions공식 문서 

 

name: client
on:
  push:
    branches:
      - {이 '브랜치' 에 push했을 때 action 실행}
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
        run: |
          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://{S3에 있는 내 버킷 이름}\
            --delete
        working-directory: {경로}