CI/CD (DevOps와 동일한 말 아님)
- CI : Continuous Integration(지속적 통합)
: 소스 변경 시 올바른지 확인하는 과정 거침
: 테스트, 빌드 등을 확인하여 통합
- CD : Continuous Deployment(지속적 배포)
: 전달(Delivery) or 배포(Deployment)
: CI를 통해 문제 없음을 확인한 뒤 시스템에 적용하는 과정 or 고객에게 전달하는 과정
DevOps : 개발의 결과가 운영에 전달되는 개념
: CI/CD의 개념을 포괄함
CI(Continuous Integration / 지속적 통합)
- 지속적으로 소스 변경사항 추적 > 확인 절차(빌드, 테스트 등) > 통제(Notification) or Artifact 생성
1) 목적
- 통합의 지연으로 발생하는 문제 > 자주 통합하여 이를 줄여야 함
> 지연 : 변경 사항과 원본이 결합한 뒤 안정적인지 확인해야 함
: 안정적이어야 통합이라 부름
: 위의 과정(확인 과정)이 길어짐(안하게 됨) > 시간이 오래걸리기 때문
: 버그/결함이 개발을 할 때마다 증가한다고 봄 > 확인이 필요하지만 이 부분이 생략
> 혼자 개발할 경우 단순 누적 됨
> 팀 단위 개발할 경우 다른 사람이 버그를 의존하게 됨 > 심각한 결함이 노출될 수 있음
- 개발은 협업
: 다수의 개발자가 공동으로 작업할 때 (맡은 기능이 다름 > 의존성 존재)
> 다른 개발자의 변경사항을 알아야 함(=통합 =인지)
1. 오류를 서로 수정하게 되었을 때 방식이 다르다면 하나로 합치기 힘듦
2. 둘 다 잘 못 수정 > 또 다른 개발자가 이를 의존하게 되었을 때 빌드가 안되는 등의 문제 발생
: 통합의 지연이 존재할 경우의 문제 >> 자주 통합하여 문제 해결 + 빌드 시도
> 병합 충돌 >> 빠른 발견이 가능해 짐
> 빌드 오류 >> 빠른 발견이 가능해 짐
> 잠재적인 버그 확대 >> 버그에 대한 의존성의 빠른 제거가 가능 함(완벽히 제거는 불가능)
2) 협업 방식
- SCM(Software Configuration Management) 수행
: 소프트웨어 형상 관리
: 소프트웨어 개발 및 유지 보수 과정에서 발생하는 소스코드, 문서 등
각종 결과물(형상)에 대한 변경사항을 체계적으로 관리하고 제어하기 위한 활동
- SCM을 위한 방법
- VCS(Version Control System) : 버젼 관리 시스템
: 소스코드의 형상관리
: 다양한 버젼의 소프트웨어나 콘텐츠를 관리하고 추적하는 도구
: SVN, Git과 같은 솔루션 활용
~> RCS -> CVS -> SVN으로 변화
~> 최근에는 Git을 사용 (Github는 클라우드 시스템으로 둘이 다름)
- 나(우리 팀)에 맞는 VCS 선택
: 소스코드의 변경 사항 발생을 인지 가능한 VCS 선택
: Propagation까지 가능한 능력이 필요(보통 VCS가 가지고 있음)
: 지속적 통합을 자동화 할 수 있음
- SCM과 CI
: 모든 사람의 코드 변경 내용 발생 > 인지 > 변경 확정(Commit) > 검증(Compile 혹은 Build, Test 등) 수행
: 지속적 통합 수행(Commit > Build > Test > ... )
: 충돌의 조기 발견 가능
: 다른 사람의 코드와 상호작용 확인
: 버그가 자리잡기 전에 제거(버그에 대한 의존성을 조기 제거 가능함)
CD(Continuous Deployment / 지속적 배포)
: CI의 결과(Artifact / 실행 Binary) > System에 전달(지속적 전달) > System에 Install/Configuration(지속적 배포)
: 운영 단계에 적용하는 것
배포란?
- 테스트가 완료된 결과물(CI의 결과물)을 운영 시스템(Production System)에 반영하는 것
- 배포에서 사람의 개입을 줄이고 루틴화 > 오류 제거 > 자동화
Release
- 운영 시스템에 개발 결과물을 반영하는 것
- 문제가 발생한 경우 즉각적 롤백이 필요
: 개발팀에 수정 요청 > 수정까지 긴 시간이 필요 > Previous Version으로 바꿔야함(운영 입장)
: 롤백을 할 수 없는 경우가 발생한다면 매우 위험한 상태
- Old Artifact를 다시 설치하고, 설정 값들을 이전 상태로 변환시키는 행위 : 롤백
- 사용자가 이러한 경험을 최소화 할 수 있도록, 바로 Release하지 않고 운영팀이 테스트 해볼 수 있는 환경이 필요
Staging(스테이징)
- 운영 시스템에 준하는 테스트 운영 시스템에 개발 결과물 반영
: 운영 시스템 수준에서 발생할 수 있는 문제를 발견하는 것이 목적 = 결함을 초기에 발견하기 위함
: 운영 시스템과 동일하거나 유사한 형태의 시스템 준비
: 테스트 운영 시스템은 언제든 폐기 혹은 재구성이 가능해야 함
~> 원활히, 실수없이 진행, Programmable 하게 진행 => 자동화 가능
지속적 배포
: 모든 사람의 코드 변경 => 테스트 완료(CI)
: CI를 통과한 결과물의 관리 => CD
> Staging단계 -> Release단계
: CI의 결과물을 체계적으로 관리할 수 있어야 함
개발팀과 운영팀의 협업
1) 형상관리
- 개발팀 : 소스코드, 문서 등
- 운영팀 : 개발팀의 결과물(Artifact)
2) 충돌(Conflict) > 롤백
- 개발팀 : 이전의 상태로 되돌릴 수 있는 SCM 솔루션(예 : VCS) 활용
- 운영팀 : 이전 개발팀의 결과물로 시스템을 롤백
파이프라인(Pipeline)
- CI/CD 과정의 통합
- 파이프라인
: 소스 관리 시스템과 통합이 필요
~> VCS 부터 파이프라인이 시작된다고 생각
: CI/CD 파이프라인의 시작점 = Commit
> Commit(커밋) : 변경사항을 소스 관리 시스템에 반영하는 행위
> CI는 Commit을 확인하고 테스트를 보장해야 함 (자동화가 필요) ~> CI Build Server가 필요
> 이때, Build와 Test에서 어떤 것이 실패인지에 대하여(Failure) 고민해야 함
> 개발자의 프로세스
: SCM과 통합
: 선택한 브랜치/태그에 커밋이 발생하면 파이프라인(CI 빌드)을 시작
: 모든 커밋을 전부 CI 빌드하지 않음(선택적 적용)
: 브랜치/태그 커밋을 기준으로 선택하여 파이프라인(CI빌드)를 시작 = CI 빌드 서버의 부하를 줄임
> 커밋 전 테스트
: 알려진 다른 사람의 코드 활용 > 다른 사람 코드와 융합되었을 때 문제가 발생하는지 확인
: 변경한 코드 내 혹은 변경한 코드로 인한 영향을 파악
: 만약, 에러 발생시 다른 사람 코드의 문제라면 새로운 issue생성
> 커밋 충돌 (Conflict)
: 최신의 다른 사람의 코드와 결합에서 문제
: 동일한(유사한) 위치의 소스 코드 변경사항이 발생
: 나중에 커밋한 개발자가 어떻게 적용할 것인지 결정해주어야 함 ~> 못한다면 Review등의 행위가 필요(새로운 issue 생성)
> 빌드 실패
: 최신의 다른 사람의 코드의 의존성 확인
: 의존성 충돌 문제 확인
> CI 테스트 실패
: 다른 사람의 변경사항과 결합에서의 비즈니스 로직 검사
: 소프트웨어 통합 관점에서 유닛 테스트, 통합(integration) 테스트, E2E(end to end) 테스트 등을 수행
~> 예상 가능한 문제를 조기에 발견
: 테스트 완료시 Stable하다고 이야기 = Release 하려는 것이 목적
> 테스트는 Stable의 여부를 확인 하는 것
+) CI Pipeline의 확장
1. 품질 검사
> 기능에는 문제 없음
: 가독성을 위한 작성 스타일 검사(조직 내 규칙 준수 여부 확인)
: 버그를 유발할 수 있는 코드 패턴 검사
2. 문서화
> 개발 팀이 공유할 수 있는 정보 문서화
결론)
- 개발자간 소통 문화 / 피드백
- 개발 관련자 <-> 동료 개발자 : Messageing Service(SMS, Slack 등)
~> 여러 관련자들에게 현재의 개발 상태(성공 여부)등을 메신저 프로그램 등을 통해 공유 가능
~> 문제(Isuue)와 명확한 Feedback 전달이 가능해짐
- CD에서의 Build Management
: CI Build Server관리
> 복잡한 일 수행
- 빌드 : 모든 파일 컴파일, 모듈 별 컴파일(각 의존성에 따라 빌드를 해야함)
- 테스트 : 테스트 방법에 따라 여러 테스트 진행
- 품질검사, 문서화 : 언어, 툴에 따라 다름
> 따라서, CI Build 자체를 관리할 필요가 있음
ex) CI Build 서버에 부하가 많이 걸린다면 병렬로 처리하기 위해 서버를 늘려야 함(탄력적)
: 빌드 단계가 복잡한 이유
- 환경의 구성(언어, 운영체제, CPU 아키텍쳐 등)
- 빌드 툴체인의 다양성(make, cmake, 등)
: 테스트 단계가 복잡한 이유
- 유닛 테스트
: 언어에 따른 도구 사용
: 코드 커버리지 보고서(Artifact) 생성
- 통합 테스트
: 통합 환경 구축 및 테스트
: 데이터베이스(Clean State), 웹 서버 등... 환경 준비 필요
- E2E 테스트
: 종단(End to End)간 테스트
: 종단 테스트 환경 구축 필요
: ex) REST API의 경우, HTTP 프로토콜 상에서 API 호출(CURL 등 이용)
: 코드 검토/품질검사 단계가 복잡한 이유
- 코드 스타일(가독성) : 들여쓰기, 이름 규칙 등
- 오류 가능성 높은 코드 패턴 검출
: 복사-붙여넣기 탐지
: 함수 분기 복잡도
: 불용 코드 탐지 등
: 문서화 단계가 복잡한 이유
- 개발 문서 생성
: API Document(ex: JavaDoc 등)
- 설치 / 환경 구성 방법 등
: 동료 개발자와 공유해야 하는 다양한 정보
빌드 에이전시 구성
: 빌드하는 환경 요건에 맞는 시스템 구성
1) 가상화 기술을 활용한 Provision 기법
: 리소스의 탄력적 구성 및 확장성 확보 용이
2) 사전에 Provision 된 환경에서 빌드/테스트 수행
: 수행 전/후 Clean up을 통해 빌드/테스트가 오염되지 않도록 조치해야 함
3) 동시 실행을 통한 파이프라인 효율성 극대화
실패(Failure)의 정의
: CI/CD의 각 단계에서 발생하는 Failure
1) 자명한 Failure
: 빌드 실패 / 테스트 실패
2) 어떤 기준을 충족하지 않는 Failure
: test coverage N% 이상 만족
: 코드 품질 경고 N개 이하 만족
아티팩트(Artifact) 관리
: CI 단계에서의 결과물/부산물
: 단계별 Artifact
1) Build > Binary
2) Test > Test 보고서
3) 품질 검사 > Quality Report
4) 문서화 > 문서
: CD 파이프라인으로 연계 필요
> 빌드 결과(ex: 실행 바이너리 등)를 Staging / Deployment 단계로 전달
~> 지속적 전달 활성화
~> CD 단계에서 롤백의 기준 결과물
> 테스트 / 품질검사 / 문서화 결과를 개발자 공유 환경에 배포
진행 상황 추적
: 각 단계별 신속한 피드백 제공
> 빌드 및 테스트에 대한 실시간 보고
~> 실패의 원인(실패까지의 과정이 기록되어 있어야 함)
~> 빌드 로그 확인
> 완료된 빌드(아티팩트)의 정보 제공
> 메시징 서비스와 연계를 통한 알림 기능 : 실시간 통지
~> SCM > CI > CD : Message Service 사용
> 버그 추적 도구와의 통합 등 수행
~> Issue Tracker를 사용 (이슈 부터 시작)
~> Issue > SCM > CI > CD
'DevOps' 카테고리의 다른 글
| #6 IaC 개선(구성 관리 도구와 특징) (0) | 2025.04.26 |
|---|---|
| #5 Github에서의 Issue관리 (0) | 2025.04.26 |
| #4 VCS(버전 관리 시스템)과 Issue 관리 (0) | 2025.04.26 |
| #2 Devops 개요 (0) | 2025.04.25 |
| #1 Devops 개요 (0) | 2025.04.25 |
