아ㅏㅏㅏ 지속적 제공 vs 지속적 배포 의 차이가 뭔데

2023. 11. 20. 14:36Project 해축갤/CI CD

728x90

혼란의 시작 : 지속적 제공(Continuous Delivery)과 지속적 배포(Continuous Deployment) 구분이 안된다

https://www.redhat.com/ko/topics/devops/what-is-ci-cd?cicd=32h281b

 

CI/CD(CI CD, 지속적 통합/지속적 배포): 개념, 툴, 구축, 차이

CI/CD는 애플리케이션의 통합 및 테스트 단계부터 제공 및 배포까지 애플리케이션 라이프사이클 전체에서 지속적인 자동화와 지속적인 모니터링을 제공하는 것을 뜻합니다.

www.redhat.com

RedHat의 글을 읽다가 혼란이 왔습니다.

 

CI/CD 파이프라인

지속적인 제공이란 개발자들이 애플리케이션에 적용한 변경 사항이
버그 테스트를 거쳐 리포지토리(예: GitHub 또는 컨테이너 레지스트리)에 자동으로 업로드되는 것을 뜻하며,
운영팀은 이 리포지토리에서 애플리케이션을 실시간 프로덕션 환경으로 배포할 수 있습니다.

이는 개발팀과 비즈니스팀 간의 가시성 및 커뮤니케이션 부족 문제를 해결해 줍니다.
그러므로 지속적인 서비스 제공은 최소한의 노력으로 새로운 코드를 배포하는 것을 목표로 합니다.

 

글을 보면 지속적인 제공은 파이프라인에서 엄연히 하나의 역할을 담당하고 있고,

그 역할은 main branch 나 별도의 repository에 변경 사항을 반영한다는 것을 의미합니다.

 

2023.11.14 - [해축갤 프로젝트/CI CD] - CI(Continous Integration) 도구 선택 고민 원큐에 끝내기

 

CI(Continous Integration) 도구 선택 고민 원큐에 끝내기

2023.11.14 - [해축갤 프로젝트/CI CD] - CI(Continuous Integration) 개념, 개인 CI vs 팀 CI CI(Continuous Integration) 개념, 개인 CI vs 팀 CI 2023.10.31 - [해축갤 프로젝트/테스트 코드] - postman 띡띡딸깍 귀찮아서 테스트

xpmxf4.tistory.com

저는 CI(Continuous Integration) 과정까지는 구현했으나, Continuous Delivery 진행하지 않았습니다.

하지만 글을 읽으면서 이미 제가 하고 있는 같기도 했습니다. 프로젝트는 배포 직전의 상태까지 도달했으니까요.

 

그러다 저번에 작성한

2023.11.14 - [해축갤 프로젝트/CI CD] - CI(Continuous Integration) 개념, 개인 CI vs 팀 CI

 

CI(Continuous Integration) 개념, 개인 CI vs 팀 CI

2023.10.31 - [해축갤 프로젝트/테스트 코드] - postman 띡띡딸깍 귀찮아서 테스트 코드 짭니다 postman 띡띡딸깍 귀찮아서 테스트 코드 짭니다 매번 기능 만늘때마다 postman 띡 띡 딸깍 하며 기능 테스트

xpmxf4.tistory.com

개인 CI vs 팀 CI 구축 글에서 힌트를 얻어 그 답을 얻고

다른 분들은 고생 안하시길 바라며 글 정리해 봤습니다!

다양한 브랜치 전략 활용 시 Continuous Delivery 적용 방법

master, develop, feature

현업에서 여러 브랜치를 활용하는 팀 환경에서는

개발 브랜치, 테스트 브랜치, 스테이징 브랜치 등 다양한 브랜치를 통해

코드는 여러 단계의 검증을 거치며 이 과정은 지속적 제공의 핵심입니다.

 

각 단계(개발, 테스트, 스테이징)에서의 자동화된 테스트와 빌드는 코드가

프로덕션 환경에 배포될 준비가 되었는지 확인하는 데 중점을 둡니다.

 

즉, 각각의 브랜치에서 build&test를 돌리고 (여기까지 CI)

이때 문제가 안 생길 시에 배포를 해도 되겠다는 논의 후 이를 Master 브랜치에 push 하면

이때 또 한 번 build&test 후 master branch에 merge를 하는 과정이 continuous delivery입니다. 

개인 프로젝트의 Continuous Delivery을 하는 방법

오로지 main

제 프로젝트와 같이 단일 main branch를 사용하는

개인 프로젝트에서는 Continous Delivery 가 좀 다르게 적용됩니다. 

코드 변경 사항은 Main 브랜치에 직접 푸시되며, GitHub Actions를 통해 자동으로 build & test가 수행됩니다.

 

이 과정은 개발된 코드가 프로덕션 환경에 배포될 준비가 되었는지 확인하는 지속적 제공의 일환이기도 한 거죠.

그래서 저는 저도 모르게 Continuous Integration & Delivery를 구축한 셈이었죠.

요점

지속적 제공의 목적은 개발된 코드가 프로덕션 환경에 배포될 준비가 되도록 하는 것입니다.

이는 코드가 배포가능하고, 오류가 없다는 걸 의미합니다.

하지만 실제로 '배포'가 이뤄지지 않았다는 것입니다.

 

오늘의 글을 통해서 Continuous Integration, Continuous Delivery, Continuous Deployment의 차이를 아셨으면 좋겠습니다!

728x90