CI/CD

leekoby·2023년 4월 3일
0

개발방법

목록 보기
3/5

🔧변경내용🔨

제목날짜내용
발행일23.04.03

📌들어가기에 앞서


해당 포스트는 CI/CD를 학습한 것을 정리한 내용입니다.





🌈 CI/CD란

CI/CD는 약어로, 몇 가지의 다른 의미를 가지고 있다.

"CI"는 개발자를 위한 자동화 프로세스인 지속적인 통합(Continuous Integration)을 의미

  • CI를 성공적으로 구현할 경우 애플리케이션에 대한 새로운 코드 변경 사항이 정기적으로 빌드 및 테스트되어 공유 리포지토리에 통합
  • 여러 명의 개발자가 동시에 애플리케이션 개발과 관련된 코드 작업을 할 경우 서로 충돌할 수 있는 문제를 해결할 수 있다.

"CD"는 지속적인 서비스 제공(Continuous Delivery) 및/또는 지속적인 배포(Continuous Deployment)를 의미

  • 이 두 용어는 상호 교환적으로 사용
  • 두 가지 의미 모두 파이프라인의 추가 단계에 대한 자동화를 뜻함
  • 때로는 얼마나 많은 자동화가 이루어지고 있는지를 설명하기 위해 별도로 사용



CI/CD의 단계

일반적인 앱의 개발 및 유지보수 단계는 아래와 같다.

여기서 지속적 통합 및 지속적 전달을 단계별로 생각해볼 수 있다.

[그림] 일반적인 앱의 개발 및 유지보수 단계


지속적 통합(Continuous Integration, CI)

개발자를 위한 자동화 프로세스라고 볼 수 있다

Code - Build - Test 단계에서 적용해 볼 수 있다.

  • Code : 개발자가 코드를 원격 코드 저장소 (Ex. github repository)에 push하는 단계

  • Build : 원격 코드 저장소로부터 코드를 가져와 유닛 테스트 후 빌드하는 단계

  • Test : 코드 빌드의 결과물이 다른 컴포넌트와 잘 통합되는 지 확인하는 과정

이 과정에서

  • 개발자는 코드를 자주 원격 코드 저장소에 push
  • 테스트 및 빌드를 하며 빌드 결과를 통해 빌드가 성공했는지 실패했는지 확인
  • 통합 테스트 결과를 통해 개선 방안을 찾는다.

이 지속적인 통합 과정을 통해

  • 개발자는 버그를 일찍 발견
  • 테스트가 완료된 코드에 대해 빠른 전달이 가능
  • 지속적인 배포가 가능

지속적 통합은 모든 코드 변화를 하나의 리포지토리에서 관리하는 것 부터 시작

  • 모든 개발팀이 코드의 변화를 확인할 수 있기 때문에, 투명하게 문제점을 파악할 수 있다.
  • 잦은 풀 리퀘스트(pull request)와 머지(merge)로 코드를 자주 통합
  • 이 때, 기본적인 테스트도 작동시킬 수 있다.

이렇게 지속적 통합을 통해 개발팀은 각자 개발한 코드를 이른 시점에 자주 합치고 자주 테스트 해볼 수 있다.

  • 지속적 통합으로 보안 이슈, 에러 등을 쉽게 파악할 수 있어 해당 이슈를 빠르게 개선할 수 있다.
  • 이전에는 각자 개발자가 작성한 코드를 합치고 난 후, 모두 모여서 빌드를 시작하고 나서야 문제점을 파악할 수 있었다.
  • 지속적 통합이 적용된 개발팀은 코드를 머지하기 전, 이미 빌드 오류나 테스트 오류를 확인하여 훨씬 더 효율적인 개발을 할 수 있게 된다.

지속적 배포(Continuous Delivery/Deployment, CD)

지속적인 서비스 제공(Continuous Delivery)지속적인 배포(Continuous Deployment)를 의미

이 두 용어는 상호 교환적으로 사용

Release - Deploy - Operate 단계에서 적용해 볼 수 있다.

  • Release : 배포 가능한 소프트웨어 패키지를 작성

  • Deploy : 프로비저닝을 실행하고 서비스를 사용자에게 노출

    • 실질적인 배포 부분
  • Operate : 서비스 현황을 파악하고 생길 수 있는 문제를 감지

지속적 배포의 경우, 코드 변경 사항의 병합부터 프로덕션에 적합한 빌드 제공에 이르는 모든 단계로, 테스트 자동화와 코드 배포 자동화가 포함

이 프로세스를 완료하면 프로덕션 준비가 완료된 빌드를 코드 리포지토리에 자동으로 배포할 수 있기 때문에 운영팀이 보다 빠르고 손쉽게 애플리케이션을 프로덕션으로 배포할 수 있다.

실리콘밸리 테크 기업들은 다양한 모니터링 툴과 장애 대응 프로세스를 마련해 배포에 대한 자신감을 높여 조직의 비즈니스 역량을 키우고 있다.
뱅크셀러드 - 하루에 1000번 배포하는 조직 되기


지속적 배포 사례

[그림] 지속적 배포 사례

  • 지속적 배포의 가장 흔한 사례가 Github Page
  • 지정해둔 디렉터리에 정해진 방식에 따라 잘 커밋하기만 하면, Github Page가 알아서 해당 index.html 파일과 해당 디렉터리에 있는 파일을 잘 번들링해서 Github Page 서버에 업로드
  • 자동으로 인터넷에 배포가 되었고, 주변 가족이나 친구들에게 쉽게 만든 결과물을 공유할 수 있었다.
  • 프로젝트에서 Github Page 배포에 성공했다면, 이미 지속적 배포를 경험해봤다고 할 수 있을까...



CI/CD의 영역

CI/CD는 지속적 통합 및 지속적 제공(CD, Continuous Delivery)의 구축 사례만을 지칭할 때도 있고, 지속적 통합, 지속적 제공, 지속적 배포라는 3가지 구축 사례 모두를 의미하는 것일 수도 있다.

좀 더 복잡하게 설명하면 "지속적인 서비스 제공"은 때로 지속적인 배포의 과정까지 포함하는 방식으로 사용되기도 한다.

  • 결과적으로 CI/CD는 파이프라인으로 표현되는 실제 프로세스를 의미

  • 애플리케이션 개발에 지속적인 자동화 및 지속적인 모니터링을 추가하는 것을 의미

이 용어는 사례별로 CI/CD 파이프라인에 구현된 자동화 수준 정도에 따라 그 의미가 달라진다.

CI를 먼저 추가한 다음 클라우드 네이티브 애플리케이션의 일부로서 배포 및 개발 자동화를 구현할 수 있다.




📚 레퍼런스

뱅크셀러드 - 하루에 1000번 배포하는 조직 되기

지속적 제공(CD, Continuous Delivery)

클라우드 네이티브 애플리케이션

0개의 댓글