전통적 인도 프로세스의 한계점

1. 느린 인도 기간

• 개발 요구사항이 정의된 때로부터 제품 전달이 완료되기까지 긴 시간 소요

2. 느린 피드백 주기

• 개발팀의 효율성 향상에 걸림돌로 작용

3. 자동화 미비

• 릴리스 회수가 적으므로 자동화 필요 감소 -> 릴리스 기간 예측 어려워짐

4. 핫픽스 위험성

• 긴급한 코드 변경에 대하여 충분한 테스트가 이루어질 수 없는 위험

5. 개발문화 건전성 제한

• 팀 스트레스, 의사소통 부족, 책임의 분산, 낮은 업무 만족도

해결책 : 지속적 인도/배포 방식(CD)

1. 변경 내용이 단지 코드 한 줄이라고 할 때,

• 이를 배포하는 데 어느 정도 시간이 소요되는가?

2. 이 배포 작업을 반복해서 인정적으로 수행할 수 있는가?

CD의 두 가지 의미

지속적 제공 (Continuous Delivery): 코드 변경 사항이 항상 배포 가능한 상태로 준비되도록 자동화하는 단계까지 (테스트 통과 후).
지속적 배포 (Continuous Deployment): 지속적 제공의 다음 단계로, 테스트를 통과한 코드를 최종 사용자에게 자동으로 릴리스(배포)하는 단계까지

해결안 : 프로세스의 각 단계를 자동화

1. 빠른 제품 인도

2. 짧은 피드백 주기

3. 위험도가 낮은 릴리스 : 반복과 롤백

4. 유연한 릴리스 정책 결정 가능

Git을 활용한 SCM에서 논리적 연관성이 있는 변경사항을 묶어 잘게 자주 커밋하는 것과 유사

SCM 이란? : 공급망 관리(SCM)는 원자재 조달부터 최종 목적지에서 제품 배송에 이르기까지 제품이나 서비스와 관련된 상품, 데이터 및 재정의 흐름을 관리하는 것을 말합니다. SCM의 목표는 효율성, 품질, 생산성 및 고객 만족도를 향상시키는 것입니다.

그럼 CI/CD가 무엇일까?

지속적 통합(CI : Continuous Integration)

1. 코드가 올바르게 빌드 및 통합되는지를 자동으로 확인

• 레포지토리에서 코드를 체크아웃
• 빌드 (컴파일 및 링크 등)를 수행하고 단위테스트(UT : Unit Test)를 행함.
  - 테스트 커버리지 (Test Coverage) 리포트 생성

2. 코드 품질을 검증

• 정적 분석을 통한 규칙 검사
• 코딩 규약 등의 준수 여부 검사

개발팀에 1차적인 피드백 제공

자동 인수 테스트

1. 인수 테스트(UAT : User Acceptance Test)

• 제품이 릴리스할 준비가 되었는지를 "사용자(고객)요구사항에 견주어" 확인
• 전통적으로 QA(Quality Assurance)팀의 역할
• 통합 테스트, 인수 테스트, 비기능적 분석(성능, 확장성, 보안...)등을 포함

2. CD 파이프라인에 통합

• 품질 점검을 나중에 하는 것이 아니라 개발 중에 제품에 내재시키자는 것
• 개발자가 구현을 마치는 즉시 고객이 원하는 제품인지를 검증
• 소프트웨어의 인도 결정을 자동화한다는 뜻

구성관리

1. 구성관리(Configuration Management)

• 소프트웨어와 환경 변화를 추적하고 제어
• 전통적으로 운영(Operation)팀의 역할
• 필수 도구 준비와 설치
• 응용의 배포와 관련한 다양한 서비스 인스턴스와 배포 버전 관리

2. CD 파이프라인에 통합

• 프로덕션 환경의 응용을 자동으로 구성하고 배포
• 구성 관리 도구를 이용하여 구성 관리 파일을 버전 관리 시스템에 저장하고 변경 이력 추적

CD를 위한 기술적 전제조건

1. 자동 빌드, 테스트, 패키징, 배포

• 전체 프로세스 중 자동화되지 않는 부분이 있다면 지속적 인도(CI)가 불가능

2. 신속한 파이프라인 실행

• 레포지토리에 커밋이 발생할 때마다 실행되어야 하므로 소요시간이 길면 안됨.

3. 신속한 장애 복구

• 신속한 롤백이 가능해야 하며, 그렇지 못할 경우 잦은 릴리스에 따른 위험도가 높아짐

4. 무중단 배포

• 잦은 (하루에도 수 회) 배포가 이루어지므로 배포 중 서비스 다운타임이 발생하면 안됨.

5. 트렁크 기반 개발(소스 코드 버전 관리)

• 로컬 브랜치에만 코드 체크인하면 코드 통합 검증이 이루어지지 않고 릴리스 회수가 줄어듬