배포

환경 종류

• Local
  각 개인의 개발 환경. 서버 x.

• Dev
  local에서 개발한 기능을 테스트하는 환경. test 서버

• Staging
  production에 배포하기 전에 보안, 성능 측정하는 환경. staging 서버

• Production
  실제 서비스를 운영하는 환경. Production 서버

Git Flow

이미지 출처 : campingcoder

CI/CD

이미지 출처 : osci

• Continuous Integration : 지속적 통합
  코드 변경사항을 자동으로 중앙 Repository에 통합하는 프로세스
  새롭게 작성한 코드 변경사항이 build + test를 진행한 후 test case에 통과했는지 확인

• Continuous Deployment/Delivery : 지속적 배포
  작성한 코드가 항상 신뢰가능한 상태가 되면 자동으로 Production 환경에 배포하는 프로세스
  dev/staging/main 브랜치에 Merge되면 코드가 자동으로 서버에 배포
  CI과정을 정상적으로 통과해야 Merge가 되고, 그 후 CD 과정을 진행

배포 시 주의점

• docker 이미지 사이즈를 경량화 해야 배포가 빨라진다.

• 호스트머신에 로그가 계속 쌓이므로 주기적으로 용량을 관리해야한다.

• 모델 코드를 확실히 Versioning해야한다. 배포되는, 배포 되었던 모델이 어떤 버전이었는지, 문제 발생 시 어떤 버전으로 롤백해야 하는지, 버전별 특징이 어떤지 확실히 기록해야한다.

• 모델 파일은 S3같은 오브젝트 저장소에 저장하는 것이 좋다.

GitHub Actions

GitHub에서 제공하는 강력한 CI/CD(지속적 통합 및 배포) 플랫폼
소프트웨어 개발 Workflow를 자동화한다.

• Workflow
  자동화된 전체 프로세스.
  YAML 파일로 작성되어 '.github/workflows' 디렉토리에 저장된다.
  다른 유저가 만든 workflow 템플릿 같은걸 사용할 수도 있다.

• workflow_예시.yaml

name: 워크플로우 이름

on: [트리거 이벤트]

jobs:
  job_id:
    runs-on: 실행 환경
    steps:
      - name: 단계 이름
        uses: 액션 또는 스크립트(없으면 run의 쉘커맨드만 실행)
        with:
          key: value
      - run: 실행할 명령어

• 일정 주기로 python이나 shell 스크립트를 실행할 수 있어 crontab을 대체해 쓰거나 데이터 수집을 주기적으로 할 때 사용하기도 한다.
  가끔 시간에 오류가 있어서 배치 서빙용으로는 부적합할수도..

• public repo는 무료지만 private repo는 유료

CI (지속적 통합) 과정

1. 트리거 발생

   코드가 리포지토리에 푸시될 때
   풀 리퀘스트가 생성될 때
   특정 이벤트가 발생할 때

2. 빌드 프로세스

   GitHub Actions가 가상 머신이나 컨테이너를 생성
   리포지토리 코드를 체크아웃
   필요한 의존성 설치

3. 테스트 실행

   자동화된 테스트 수행
   코드 품질 검사
   테스트 결과 확인

CD (지속적 배포) 과정

1. 배포 준비

   CI 과정 성공 확인
   프로덕션 환경을 위한 아티팩트 생성
   Docker 이미지 빌드 (필요한 경우)

2. 배포 승인

   자동 배포 또는 수동 승인 절차
   환경별 구성 적용
   보안 검증

3. 최종 배포

   프로덕션 환경에 코드 배포
   배포 상태 모니터링
   배포 완료 확인