01 CI/CD

1. CI/CD

1. CI/CD

• CI/CD란 Continuous Integration, Continuous Deployment
• CI/CD는 테스트(Test), 통합(Merge), 배포(Deploy)의 과정을 자동화
• CI/CD는 도구라는 느낌보다 그냥 “파이프라인” 느낌에 가까움.
• 코드 변경부터 배포까지를 자동으로 흘려보내는 설계 방식
  • 특정 기능을 개발 완료해서 Commit을 찍으면 빌드가 되게 셋팅하고,
  • 빌드가 완료되면 작성한 테스트 코드를 실행,
  • 그런 뒤 테스트가 통과하면 실제 서버 컴퓨터에 최신 코드가 배포

2. CI와 CD

• CI (Continuous Integration, 지속적 통합)
  • 개발자가 코드를 저장소(Git 등)에 올릴 때마다 자동으로 실행되는 과정
  • 코드 병합 :여러 개발자의 변경 사항을 자주 하나의 브랜치에 통합
  • 자동 빌드 : 컴파일, 패키징(jar/war 생성 등)
  • 자동 테스트 : 단위 테스트, 간단한 통합 테스트 실행
  • 품질 검증 : 테스트 실패, 빌드 실패 시 즉시 감지
• CD (Continuous Delivery / Continuous Deployment, 지속적 전달 / 배포)
  • CI를 통과한 결과물을 실제 실행 환경까지 가져가는 단계
  • Continuous Delivery : 운영 배포 직전 단계까지 자동화 / 운영 배포는 사람이 버튼을 눌러서 수행
  • Continuous Deployment : 운영 환경까지 완전 자동 배포 / 머지 → 바로 서비스 반영

2. CI/CD 도구

1. 통합 CI/CD

• 하나의 파이프라인에서 코드 변경 감지부터 빌드, 테스트, 배포까지 전 과정을 담당
  • 중앙에서 흐름을 제어하기 때문에 가시성이 높고, 소규모 팀에서는 구축이 단순
  • 반면 파이프라인이 비대해지면 역할 과부하가 생기기 쉬워 CI와 CD 책임 분리가 어려워질 수 있음

  • 예시

    도구	주요 용도	특징	주 사용 환경
    Jenkins	CI + CD	높은 확장성, 플러그인 기반	온프레미스, 엔터프라이즈
    GitLab CI/CD	CI + CD	GitLab 내장, 설정 일관성	GitLab 중심 조직
    GitHub Actions	CI + CD	설정 단순, SaaS 친화	GitHub 사용 팀
    Azure DevOps	CI + CD	MS 생태계 통합	대기업, MS 환경

2. CD 특화 도구

• 빌드 결과물은 이미 준비되어 있다는 전제하에 “어떻게, 언제, 어떤 상태로 배포할 것인가”에만 집중
• Git 상태를 기준으로 실제 배포 상태를 동기화하는 방식이 많아 롤백과 감사
• 쿠버네티스 환경에서 스프링 애플리케이션 운영 시 표준에 가까움

• 예시

  도구	배포 방식	특징	대상 환경
  Argo CD	GitOps	선언적 배포, 강력한 가시성	Kubernetes
  Flux	GitOps	경량, 단순 구조	Kubernetes
  Spinnaker	파이프라인	대규모 배포 전략	멀티 클라우드

3. 빌드도구

• 소스 코드를 실행 가능한 결과물로 변환하는 역할만 담당
• CI/CD 파이프라인에 포함되지만, 도구 자체는 파이프라인과 독립적이어야 유지보수가 쉬움
• 스프링 프레임워크에서는 빌드 도구가 애플리케이션 구조를 침범하지 않도록 task와 profile을 명확히 분리.

• 예시

  도구	언어/프레임워크	역할	특징
  Maven	Java / Spring	빌드, 의존성 관리	안정적, 표준화
  Gradle	Java / Spring	빌드, 자동화	빠른 빌드, 유연성

4. 기타

• CI/CD의 신뢰성과 재현성을 보장하는 보조 인프라
• 이미지는 실행 환경을 고정하고, 아티팩트와 레지스트리는 결과물을 안전하게 보관
• 품질·보안 도구는 배포 이전에 실패를 강제로 차단해 운영 리스크를 줄임

• 예시

  구분	도구	역할	특징
  이미지	Docker	실행 환경 패키징	환경 불일치 제거
  아티팩트	Nexus	라이브러리 저장	사내 의존성 관리
  아티팩트	Artifactory	결과물 저장	멀티 포맷 지원
  레지스트리	ECR	이미지 저장	AWS 관리형
  품질	SonarQube	코드 분석	품질 게이트
  보안	Snyk	취약점 검사	배포 전 차단

3. jenkins와 github Actions

1. jenkins

• Jenkins는 특정 방식이나 철학을 강요하지 않는 자동화 서버
• CI만 써도 되고, CD까지 확장해도 되며, 빌드 서버로만 써도 됨
• 특징
  • 플러그인 중심 구조
    • 거의 모든 기능이 플러그인으로 확장
    • 빌드, 테스트, 배포, 알림, 보안까지 조합 가능
  • 설치형(자체 운영)
    • SaaS가 아니라 직접 설치·운영.
    • 자유도는 높지만 서버 관리 책임이 따름
  • 파이프라인 코드화
    • Jenkinsfile로 파이프라인을 코드로 관리.
    • 버전 관리, 리뷰가 가능.
  • 환경 독립성
    • 온프레미스, 클라우드, 컨테이너 어디서든 동일하게 동작

2. github Actions

• GitHub 이벤트(push / pull request / tag / release)를 트리거로 동작하는 자동화 플랫폼
• 이벤트 기반 자동화가 핵심
• 특징
  • GitHub 완전 통합
    • 저장소 설정만으로 바로 사용
    • 별도 서버 구축 불필요
  • YAML 기반 워크플로
    • 설정이 단순하고 가독성 높음
  • SaaS 러너 제공
    • GitHub가 실행 환경 제공
    • 관리 부담 거의 없음
  • 액션 마켓플레이스
    • 재사용 가능한 액션 다수 존재

3. Jenkins와 gitHubActions

• 비교

  구분	Jenkins	GitHub Actions
  설치/운영	직접 운영	SaaS
  설정 방식	Jenkinsfile	YAML
  자유도	매우 높음	상대적으로 제한
  운영 부담	큼	거의 없음
  CD 적합성	가능하나 위험	단순 배포만 적합