CICD

zioo·2022년 1월 2일
0

Backend

목록 보기
13/40

CI/CD의 배경

✔️ 전통적인 배포 파이프라인

  1. Version Control
    코드 변경 사항을 커밋한다.
  2. Acceptance tests
    빌드/컴파일된 코드에 테스트를 수행한다.
  3. Independent Deployment
    컴파일 후 테스트에 성공한 아티팩트를 개발환경에 배포한다.
  4. Production Deployment
    Independent Deployment와 유사한 환경이야한다. production 서버에 코드를 배포한다.
  • 위와같은 전통적 배포 과정에서는 사람의 실수로 문제가 발생할 수 있다.
  • 분업과 협업에서 코드 Merge 과정은 까다로울 수 밖에 없으며 테스트에 큰 자원이 소모된다.
  • 각자의 브랜치가 개발되는 기간이 늘어나면 통합의 어려움이 증대한다. (충돌될 위험이 커지며 이를 해결하는데 리소스를 낭비하게 된다.)

위와 같은 문제점들을 해결함과 동시에 빌드 및 기능 검증을 위한 새로운 방법을 확보함으로써 개발과 배치 속도를 개선하고자 하였다.

👍 기대 효과

  • 빠른 개발 및 적용
  • 안정적 시스템 운영
  • 단위 테스트 및 테스트주도 개발 방법
  • 테스트 자동화 구축 → 기존 코드와 신규 코드간 충돌을 발견, 빠르게 자주 수정 가능 (여러 사람이 작성한 코드가 병합될 때 생기는 문제를 미리 감지)
  • 매일 코드 변경을 커밋하도록 개발자 독려
  • 시스템과 어플리케이션을 최대한 최신상태로 유지

CI

Continuous Integration(지속적 통합)으로 '코드에 대한 통합'을 '지속적'으로 진행함으로써 품질을 유지하자는 개념

예를 들면 여러명의 개발자가 하나의 프로젝트를 진행할 때 아래와 같은 과정을 지속적으로

1. 모든 개발자는 퇴근하기 전에 자신의 코드를 중앙 코드와 통합한다.

2. 통합된 코드에서 본인의 코드가 제대로 동작하는지 테스트한다.

3. 통합된 코드가 제대로 빌드되는지 테스트한다.

4. 결과를 정리하고. 버그가 있다면 다음날 업무 목록에 적어둔다.

해야하는데 번거로움이 있으므로 git 코드를 올려놓으면 알아서 테스트와 빌드를 수행하고 결과를 정리해 주는 것으로 아래와 같이 단순화 될 수 있다.

1. 모든 개발자는 퇴근하기 전에 자신의 코드를 중앙 코드와 통합한다.

2. 다음날 출근시 메일로 발송된 결과 리포트를 확인하고 버그가 있으면 수정한다.

따라서 사실상 CI는 빌드 및 테스트 자동화로 볼 수 있다.

CD

Continuous Delivery 또는 Continuous Deployment(지속적 배포)로 소프트웨어가 항상 신뢰 가능한 수준에서 배포될 수 있도록 지속적으로 관리하자는 개념

CI를 통한 지속적인 빌드와 테스트를 진행하고 통과한 코드를 테스트서버와 운영서버에 바로 배포해 반영하는 것이다.
따라서 CD는 배포 자동화로 볼 수 있다.

CI/CD 도구

  1. Jenkins
  2. Travice CI
  3. Bamboo
  4. Circle CI
  5. TeamCity

참조

https://itholic.github.io/qa-cicd/
https://velog.io/@hanblueblue/CIContinuous-Integration-CDContinuous-Delivery
CI 툴 비교 : https://elfinlas.github.io/2019/08/14/ci-tool/
profile

0개의 댓글