지속적 통합, 지속적 제공, 지속적 배포 비교
지속적 관행의 차이점에 대해 알아보기
Sten Pittet
기고 작가
CI 및 CD는 최신 개발 관행과 DevOps에서 자주 사용하는 두 개의 약어입니다. CI는 지속적 통합의 약자로, 개발자가 코드 변경 사항을 자동화된 빌드와 테스트가 실행되는 중앙 집중식 리포지토리에 자주 병합하는 DevOps의 기본적인 모범 사례입니다. 하지만 CD는 지속적 제공이나 지속적 배포 중 어떤 것이든 의미할 수 있습니다.
지속적 통합, 지속적 제공, 지속적 배포(CI/CD)의 차이점은 무엇입니까?
지속적인 통합
지속적 통합을 실행하는 개발자는 변경 사항을 최대한 자주 메인 브랜치에 병합합니다. 빌드를 만들고 빌드에 대해 자동화된 테스트를 실행하면 개발자의 변경 사항이 검증됩니다. 이렇게 하면 릴리스 브랜치에 변경 사항을 병합하기 위해 릴리스 날짜를 기다릴 때 발생할 수 있는 통합의 어려움을 피할 수 있습니다.
지속적 통합은 새 커밋이 메인 브랜치에 통합될 때마다 애플리케이션이 중단되지 않는지 확인하기 위한 자동화 테스트에 중점을 둡니다.
지속적 배포 (Continuous Delivery)
지속적 제공은 빌드 단계 이후에 모든 코드 변경 사항을 테스트 및/또는 프로덕션 환경에 자동으로 배포하기 때문에 지속적 통합이 확장된 것입니다.
즉, 자동 테스트 외에도 자동 릴리스 프로세스가 있으며 버튼을 한 번 클릭하여 언제든지 애플리케이션을 배포할 수 있습니다.
이론상으로는 지속적 제공을 사용하면 매일, 매주, 2주마다 또는 비즈니스 요구 사항에 맞는 방식으로 릴리스할 수 있습니다. 하지만 지속적 제공의 진정한 이점을 누리려면 최대한 빨리 프로덕션에 배포하여 문제 발생 시 쉽게 해결할 수 있는 소량으로 릴리스해야 합니다.
솔루션 보기
Open DevOps로 소프트웨어를 구축 및 운영
관련 자료
DevOps 파이프라인이란 무엇입니까?
지속적 배포
지속적 배포는 지속적 제공보다 한 단계 더 나아갑니다. 이렇게 하면 생산 파이프라인 모든 단계를 거치는 모든 변경 사항이 고객에게 릴리스됩니다. 사용자의 개입은 없으며 테스트에 실패해야만 새로운 변경 사항을 프로덕션에 배포할 수 없습니다.
지속적 배포는 더 이상 "릴리스 날짜"가 없기 때문에 고객과의 피드백 루프를 가속화하고 팀의 부담을 덜어주는 데 훌륭한 방법입니다. 개발자는 소프트웨어 구축에 집중할 수 있으며 작업을 마친 후 몇 분 만에 작업이 구현됩니다.
관행이 서로 관련되어 있는 방법
간단히 말해서 지속적 통합은 지속적 제공과 지속적 배포 모두의 일부입니다. 그리고 지속적 배포는 릴리스가 자동으로 이루어진다는 점만 빼면 지속적 제공과 같습니다.
각 관행의 이점은 무엇입니까?
What are the benefits of each practice?
지속적 통합, 지속적 제공, 지속적 배포의 차이점을 설명했지만 채택해야 할 이유는 아직 알아보지 못했습니다. 각 방법을 구현하는 데에는 당연히 비용이 들지만 이점이 훨씬 큽니다.
지속적인 통합
필요한 것(비용)
- 팀은 각 새로운 기능, 개선 또는 버그 수정에 대해 자동화된 테스트를 작성해야 합니다.
- 메인 리포지토리를 모니터링하고 새 커밋이 푸시될 때마다 자동으로 테스트를 실행할 수 있는 지속적 통합 서버가 필요합니다.
- 개발자는 가능한 한 자주, 적어도 하루에 한 번은 변경 사항을 병합해야 합니다.
얻는 것
- 회귀는 자동 테스트를 통해 조기에 감지되므로 프로덕션 환경에 제공되는 버그가 적습니다.
- 모든 통합 문제가 일찍 해결되었으니 릴리스 구축이 쉽습니다.
- 개발자가 빌드를 중단하자마자 알림을 받고 다른 작업으로 넘어가기 전에 수정 작업을 할 수 있으므로 컨텍스트 전환이 줄어듭니다.
- 테스트 비용이 대폭 절감됩니다. CI 서버는 몇 초 만에 수백 개의 테스트를 실행할 수 있습니다.
- QA 팀은 테스트에 걸리는 시간을 줄이고 품질 문화를 크게 개선하는 데 집중할 수 있습니다.
지속적 배포 (Continuous Delivery)
필요한 것(비용)
- 지속적 통합의 탄탄한 기반이 필요하며 테스트 스위트는 코드베이스를 충분히 다루어야 합니다.
- 배포를 자동화해야 합니다. 트리거는 여전히 수동이지만 배포가 시작되면 수동으로 개입할 필요가 없습니다.
- 팀은 불완전한 기능이 프로덕션 환경에 있는 고객에게 영향을 미치지 않도록 기능 플래그를 수용해야 할 가능성이 높습니다.
얻는 것
- 소프트웨어 배포의 복잡성이 사라졌습니다. 팀은 더 이상 릴리스 준비에 며칠씩 보낼 필요가 없습니다.
- 더 자주 릴리스하여 고객과의 피드백 루프를 가속화할 수 있습니다.
- 작은 변화에 대한 의사 결정 부담이 훨씬 적기 때문에 더 빠르게 반복할 수 있습니다.
지속적 배포
필요한 것(비용)
- 테스트 문화가 최고여야 합니다. 테스트 스위트의 품질이 릴리스의 품질을 결정합니다.
- 문서화 프로세스는 배포 속도에 맞아야 합니다.
- 기능 플래그는 다른 부서(지원, 마케팅, PR)와 협력할 수 있도록 중요한 변경 사항을 발표하는 프로세스의 본질적인 부분이 됩니다.
얻는 것
- 릴리스를 위해 개발을 일시 중지할 필요가 없기 때문에 더 빨리 개발할 수 있습니다. 배포 파이프라인은 변경될 때마다 자동으로 트리거됩니다.
- 작은 변경 사항을 배포하면 릴리스가 덜 위험하고 문제 발생 시 수정하기도 더 쉽습니다.
- 고객은 매달, 매 분기 또는 매년이 아니라 매일 지속적으로 개선되고 품질이 향상되는 것을 보게 됩니다.
지속적 통합과 관련된 기존 비용 중 하나는 CI 서버의 설치와 유지 관리입니다. 하지만 모든 Bitbucket 리포지토리 자동화를 추가하는 Bitbucket Pipelines와 같은 클라우드 서비스를 사용하면 이 방식을 채택하는 데 드는 비용을 크게 줄일 수 있습니다. 리포지토리 루트에 구성 파일을 추가하기만 하면 메인 브랜치에 새 변경 사항이 푸시될 때마다 실행되는 지속적 배포 파이프라인을 만들 수 있습니다.
지속적 통합에서 지속적 배포로 전환
아직 사용자 없이 새 프로젝트를 시작하는 경우 모든 커밋을 프로덕션에 쉽게 배포할 수 있습니다. 배포를 자동화하고 고객 없이 알파 버전을 프로덕션에 릴리스하는 것부터 시작할 수도 있습니다. 그러면 테스트 문화를 발전시키고 애플리케이션을 빌드하면서 코드 커버리지를 늘릴 수 있습니다. 사용자를 등록할 준비가 되면 새로운 변경 사항을 모두 테스트한 후 프로덕션에 자동으로 릴리스되는 뛰어난 지속적 배포 프로세스를 갖추게 될 것입니다.
하지만 이미 고객을 둔 기존 애플리케이션이 있다면 속도를 늦추고 지속적 통합과 지속적 제공부터 시작해야 합니다. 자동으로 실행되는 기본 단위 테스트를 구현하는 것부터 시작하세요. 아직 복잡한 엔드투엔드 테스트 실행에 집중할 필요가 없습니다. 그 대신 최대한 빨리 배포를 자동화하고 스테이징 환경으로의 배포가 자동으로 이루어지는 단계에 도달해야 합니다. 그 이유는 자동 배포를 사용하면 릴리스를 조정하기 위해 주기적으로 작업을 중단하는 대신 테스트 개선에 에너지를 집중할 수 있기 때문입니다.
매일 소프트웨어를 릴리스하기 시작하면 지속적 배포를 살펴볼 수 있습니다. 하지만 문서, 지원, 마케팅 등 조직의 나머지 부분도 준비되어 있어야 합니다. 기능은 새로운 릴리스 케이던스에 맞게 조정되어야 하며 고객에게 영향을 미칠 수 있는 중대한 변경 사항을 놓치지 않는 것이 중요합니다.
가이드 읽어보기
이 문서 공유
다음 주제
여러분께 도움을 드릴 자료를 추천합니다.
이러한 리소스에 책갈피를 지정하여 DevOps 팀의 유형에 대해 알아보거나 Atlassian에서 DevOps에 대한 지속적인 업데이트를 확인하세요.
DevOps 커뮤니티
블로그 읽기
