CICD 개념
- CI : 지속적 통합(여러 branch에서 변경된 소스를 하나의 branch에 통합하는 과정)
- CD : 지속적 배포(변경된 소스가 자동으로 빌드, 테스트, 배포되는 과정)
개념에 대한 자세한 내용은 아래 URL 참고해주세요.
https://seosh817.tistory.com/104
CICD 사례
(1) 시스템(서비스)별로 master branch가 있고, 이를 운영 환경에 배포한다.
(2) 프로젝트 시작 시 master branch를 복사하여 새로운 branch를 만든다.(Project A branch)
(3) 개발자는 자신이 포함된 프로젝트에 생성된 Project branch에서 개인 branch를 만든다.
(4) 개발 완료되면 Project branch에 merge 하여 배포 후 테스트한다.
(5) master branch에 merge 하여 운영 환경에 배포한다.
- 위 방식의 특징
(1) 개발자/프로젝트 단위로 branch를 생성하여 개발/테스트를 한다.
(2) 개발자 branch 별로 CICD 환경이 구성되지 않아 project branch에 merge 해야 테스트 가능하다
(3) master branch도 수시로 코드가 변경되는데, project branch에 정기적으로 pull이 필요하다
(프로젝트에서 개발한 소스에 기존 운영 환경에 배포된 부분이 반영되지 않고 배포된 적 있음)
(1) 개발자의 로컬 환경에서 개발한 부분이 정상적으로 동작하는지 확인한다.
(2) master 또는 project branch에 merge 한 뒤, 개발 환경에 배포하여 정상적으로 동작하는지 확인한다.
(3) 스테이징 환경에 배포하여 테스트한다.
(4) 운영 환경에 배포하여 정상적으로 동작하는지 확인한다.
(5) DR 환경에도 배포하여 운영 환경 장애 발생 시 DR 환경을 대체재로 사용할 수 있도록 한다.
- 위 방식의 특징
(1) 배포/테스트 방식이 일관성이 부족하다.(특정 환경 배포 여부는 프로젝트마다 다르며, 강제할 수 있는 방법이 없다)
(2) master branch에 merge 하는 순서가 중요하다.(프로젝트별 일정에 맞게 순서 조정함)
CICD 자동화
AWS devops pipeline의 특징은 아래와 같다.
(1) CICD 통합
CodeCommit / Git에서 개발자별로 branch를 생성한다.
개발한 소스를 branch에 commit 하면, branch 별로 자동 배포된다.
배포 과정에서 branch 별로 테스트 환경을 생성하고 모든 테스트를 통과해야 master branch로 merge 가능하다.
master branch에 merge 하면 자동 배포되어 새로운 운영 환경이 생성된다.
기존 운영 환경에서 새로운 운영 환경으로 트래픽을 점진적으로 유입되도록 한다.
(2) 배포에 오랜 시간 소요
개발자들이 개발한 소스를 commit 한 다음, 테스트 통과하기까지 꽤 오랜 시간 걸린다.
→ 한 개발자가 여러 branch를 만들어 차례로 테스트하기도 한다.
(3) 모든 과정의 개발 필요
애플리케이션 소스 이외에 배포 시 AWS 테스트 환경을 만드는 부분, 테스트 방법 모두 개발해야 한다.(주로 yaml 형식으로 개발됨)
참고
[AWS CICD 파이프라인 개념]
https://aws.amazon.com/ko/getting-started/hands-on/set-up-ci-cd-pipeline/
'CICD' 카테고리의 다른 글
| Git, SVN 개요 (0) | 2022.03.13 |
|---|
