CI/CD

#CI(지속적 통합)에서 수행하는 작업

1. CI는 개발자가 코드를 push하거나 PR을 올릴 때마다 자동으로 실행된다.
2. 가장 먼저 수행하는 것은 의존성 설치로, npm install이나 pip install 같은 명령으로 필요한 패키지를 준비한다.
3. 다음으로 린트(Lint)를 실행해 코드 스타일이나 문법 오류를 검사한다.
4. 린트가 통과하면 유닛 테스트와 통합 테스트를 실행해 로직이 올바른지 확인한다.
5. 테스트가 모두 통과하면 빌드를 수행해 소스코드를 실행 가능한 결과물로 변환한다.
6. 빌드 결과물이 정상적으로 생성됐는지 확인하는 것까지가 CI의 범위이다.
7. 즉 CI의 목적은 "이 코드가 문제없이 동작하는가"를 빠르게 검증하는 것이다.

#CD(지속적 배포)에서 수행하는 작업

1. CD는 CI가 성공적으로 끝난 이후에 이어서 실행된다.
2. 먼저 빌드 결과물을 Docker 이미지로 만들거나, 압축 파일로 패키징하는 작업을 수행한다.
3. 그 결과물을 컨테이너 레지스트리(Docker Hub, ECR 등)나 스토리지에 업로드한다.
4. 이후 실제 서버나 클라우드 환경에 해당 결과물을 배포한다.
5. 배포 방식은 환경에 따라 다른데, EC2 서버에 SSH로 접속해 실행하거나, k8s에 새 이미지를 반영하거나, Vercel·Netlify 같은 플랫폼 API를 호출하는 방식 등이 있다.
6. 배포 후에는 서버가 정상적으로 응답하는지 헬스체크를 수행하기도 한다.
7. CD의 목적은 "검증된 코드를 자동으로 사용자에게 전달하는 것"이다.

#브랜치별로 다르게 동작하는 경우

1. 보통 모든 브랜치에서 CI만 실행하고, CD는 특정 브랜치에서만 실행하도록 구성한다.

2. 예를 들어 main 브랜치에 머지될 때만 실제 운영 서버에 배포하는 방식이다.

3. develop 브랜치에 머지될 때는 스테이징 서버에만 배포해 먼저 검증하기도 한다.

   jobs:
     deploy:
       if: github.ref == 'refs/heads/main'  # main 브랜치일 때만 배포
       needs: test
       steps:
         - run: ./deploy.sh

4. 이렇게 하면 개발 중인 코드가 실수로 운영 서버에 배포되는 상황을 방지할 수 있다.