CI/CD

📍CI/CD 이해

✅ 소프트웨어 릴리스 수명 주기를 자동화하는 프로세스
✅ 지속적 통합 (CI)

• Git 리포지토리와 같은 코드 리포지토리에서 발생
• 특정 브랜치에서 코드를 변경하고 빌드 및 테스트 수행
• 기본 브랜치를 대상으로 하는 PullRequest 생성
• 코드 검토
• 승인되면 기본 브랜치로 병합

✅ 지속적 제공 (CD)

• 변경 사항을 버그 테스트를 거쳐 리포지토리에 자동으로 업로드
• 테스트 자동화, 코드 릴리스 자동화

✅ 지속적 배포 (CD)

• 리포지토리에서 프로덕션 환경까지 자동으로 릴리스하는 것
• 수동 배포로 인한 프로세스를 줄임

---

📍형상관리 및 브랜치 전략

하단의 내용은 지난 프로젝트에서 사용한 전략입니다.

✅ 형상관리 : 소스코드 변경에 대한 모든 관리

• 새로운 기능, 테스트 등등 레포지토리에 변경을 줄 때는 무조건 이슈를 발급
• 발급된 이슈 번호를 작업 브랜치 생성시 적용
• 이슈 발급 시, (1) 어떤 기능에 대해 작업을 하는 지 설명 (2) 작업 상세 내용 (3) 참고 자료 (선택) 를 첨부하여 작성
• Pull Request 시, 관련된 이슈 번호를 첨부하고 어떤 식으로 구성되었는지 작성. main으로는 승인된 인원만 머지할 수 있고, 한 명 이상의 인원에게 Approval을 받아야 develop으로 머지 할 수 있음.

✅ 브랜치 전략

• main : 모든 변경사항은 최종적으로 main에 반영되어야 함
• develop : main으로 올리기 전까지 코드를 통합하는 브랜치
• type/#이슈번호 : 각 개발자들이 develop으로 올리기전에 작업하는 브랜치
  🗂️ feat : 새로운 기능 추가
  🗂️ fix : 버그 수정
  🗂️ refactor : 코드 리팩토링
  🗂️ test : 테스트 코드, 리팩토링 테스트 코드
  🗂️ chore : 빌드 업무 수정

---

📍Pipeline 구조 - FE

✅ 사용한 툴 : Jenkins
✅ Stage : Clone Repository - SonarQube Quality Test - Build - S3(AWS) / Storage(GCP) - CloudFront Cache Removal
✅ Credential은 Jenkins 사이트에 등록하여 사용

Clone Repository

• 깃허브 웹훅을 이용해 Develop 브랜치에 push가 생기면 해당 브랜치를 클론

SonarQube Quality Test

• 일정 기준치를 넘지 못하면 Fail이 뜨게 설정
• 기준치는 프로젝트 일정 및 상황을 고려하여 최소치로 잡음
• 기준은 Claude에 표준치를 검색하여 설정

=> 왜 도입했는가?
코드 리뷰를 하고 싶다는 팀원들의 의견이 있었으나, 다들 제대로 된 코드 리뷰를 해본 적이 없고 가이드라인이 없어서 어려워했다. 그래서 툴에 의존을 해야했고, 완전히 새러운 툴보다는 기술 세미나 때 언급이 많았던 SonarQube를 선택하게 되었다.

Build
npm으로 빌드

S3(AWS) / Storage(GCP)

• 빌드 된 내용물들을 S3, Storage로 전송
• AWS CLI, gcloud CLI로 진행

CloudFront Cache Removal

• CloudFront에 Cache가 남아있어 제대로 변경 사항이 반영이 안되는 경우가 있으므로 AWS CLI로 캐시 무효화 진행

✅ 개인적인 피드백

• Repository를 Develop으로 올리기 전에 Quality Check를 했으면 더 좋았을 것 같다. Develop으로 올리고 하니까 양이 방대해져서 수동으로 체크하기가 어려웠다.
• Monitoring/Logs에 관련된 부분이 없어서 아쉽다.
• SonarQube에서 제공하는 장점을 완전하게 활용하지 못 했다.

---

📍Pipeline 구조 - BE

✅ 사용한 툴 : Jenkins, ArgoCD
✅ Stage : Clone Repository - Build - SonarQube Quality Test - Build Docker Image - Upload Image to ECR - Upload Image to GCR - Update K8S Manifest
✅ Credential은 Jenkins 사이트에 등록하여 사용

Clone Repository

• 깃허브 웹훅을 이용해 Develop 브랜치에 push가 생기면 해당 브랜치를 클론

Build
jar 파일 생성

SonarQube Quality Test

• 일정 기준치를 넘지 못하면 Fail이 뜨게 설정
• 기준치는 프로젝트 일정 및 상황을 고려하여 최소치로 잡음
• 기준은 Claude에 표준치를 검색하여 설정

Upload Image to ECR / Upload Image to GCR

• 빌드된 내용을 Docker Image로 만듦
• 그 이미지를 ECR/GCR로 보냄

Update K8S Manifest

• 새 이미지가 빌드되면, 해당 이미지 태그로 Kubernetes 매니페스트 자동 업데이트
• 변경사항 GitOps 저장소에 커밋
• 인프라 변경사항 코드로 관리
• 배포 이력 추적 가능

✅ ArgoCD
GitOps repository hook

• Argo가 GitOps Web-hook 감지

CD - Blue/Green

• Auto Sync를 통해 클러스터 설정 자동 변경
• Argo Rollout 컨트롤러가 rollout.yaml에 정의된 전략을 기반으로 새 버전 배포
• 새 버전 Green 안정성 검증
• Health-Check 성공 후 트래픽 전환

✅ 개인적인 피드백

• Repository를 Develop으로 올리기 전에 Quality Check를 했으면 더 좋았을 것 같다. Develop으로 올리고 하니까 양이 방대해져서 수동으로 체크하기가 어려웠다.
• Monitoring/Logs에 관련된 부분이 없어서 아쉽다.
• SonarQube에서 제공하는 장점을 완전하게 활용하지 못 했다.