지속적 배포란 무엇입니까?
지속적 배포(CD)는 소프트웨어 팀과 고객에게 도움이 됩니다. 지속적 배포가 무엇인지, 그 이점, 모범 사례 등에 대해 알아보세요.
Sten Pittet
기고 작가
지속적 배포(CD)는 자동화된 테스트를 통해 코드 베이스의 변경 사항이 정확하고 안정적인지 검증하여 프로덕션 환경에 즉시 자율적으로 배포하는 소프트웨어 릴리스 프로세스입니다.
소프트웨어 릴리스 주기는 점점 진화해 왔습니다. 한 컴퓨터에서 다른 컴퓨터로 코드를 옮기고 예상대로 작동하는지 확인하는 레거시 프로세스는 오류가 발생하기 쉽고 리소스가 많이 소요되는 프로세스였습니다. 이제 도구를 통해 전체 배포 프로세스를 자동화할 수 있으므로 엔지니어링 조직은 인프라 오버헤드 대신 핵심 비즈니스 요구 사항에 집중할 수 있습니다.
지속적 배포와 지속적 제공 비교
지속적 배포와 지속적 제공의 구분은 명명법 때문에 혼동될 수 있습니다. 둘 다 약자가 CD이며 책임이 아주 유사합니다. 제공은 배포 전에 이루어집니다. 제공에서는 프로덕션 릴리스 전에 최종 수동 승인 단계가 있습니다.
다음은 둘 사이의 차이점을 기억하는 데 도움이 되는 암기법입니다. 좋아하는 온라인 상점에서 보낸 택배를 받는 것을 생각해 보세요. 택배가 도착하기를 기다릴 때는 제공 서비스에 해당합니다. 이러한 과정이 제공 단계입니다. 택배가 도착하면 택배를 열고 내용물을 검토해서 예상한 물건이 왔는지 확인합니다. 물건이 잘못 왔으면 택배를 거부하고 반품할 수 있습니다. 택배의 내용이 맞으면 새로 구매한 물건을 “배포”하고 사용할 준비가 된 것입니다.
제공 단계에서 개발자는 코드 변경 사항을 검토하고 병합한 다음 아티팩트로 패키징합니다. 그리고 패키지는 프로덕션 환경으로 이동하여 배포를 위해 승인되기를 기다립니다. 배포 단계에서는 자동 검사 시스템을 통해 패키지를 열고 검토합니다. 검사에 실패하면 패키지가 거부됩니다.
검사를 통과하면 패키지가 자동으로 프로덕션에 배포됩니다. 이처럼 지속적 배포는 완전한 엔드투엔드 자동 소프트웨어 배포 파이프라인입니다.
솔루션 보기
Open DevOps로 소프트웨어를 구축 및 운영
관련 자료
자동화된 테스트에 대해 자세히 알아보기
지속적 배포의 이점은 무엇입니까?
지속적 배포는 소프트웨어 개발 팀에게 생산성 면에서 놀라운 이점을 선사합니다. DevOps와 지속적 배포를 결합하면 팀에서 릴리스를 상당히 가속화할 수 있습니다. 변경될 때마다 배포 파이프라인이 자동으로 트리거되므로 팀이 더 빠르게 개발할 수 있습니다. 팀에 새 제품 또는 기능에 대한 아이디어가 있으면 코드를 푸시하는 즉시 고객이 받을 수 있습니다. 지속적 배포를 통해 팀에서는 변경 사항을 소규모로 배포할 수 있으므로 릴리스의 위험이 줄어들고 문제가 발생할 경우 쉽게 해결할 수 있습니다.
비즈니스 관점에서 보면 지속적 제공을 통해 회사는 새로운 아이디어와 기능을 신속하게 배포하고 검증하여 변화하는 시장 수요에 대응할 수 있습니다.
지속적 배포 도구
자동 테스트를 채택한 후에는 테스트 스위트가 코드베이스를 얼마나 포함하는지 알 수 있는 테스트 커버리지 도구와 결합하는 것이 좋습니다.
80% 이상의 커버리지를 목표로 하는 것도 좋지만 높은 비율의 커버리지를 효과적인 테스트 스위트와 혼동하지 않도록 합니다. 코드 검사 도구는 테스트되지 않은 코드를 찾을 수 있지만 결국 차이는 테스트의 품질에서 옵니다.
막 시작한 단계라면 코드베이스의 100% 커버리지를 얻기 위해 서두르지 말고 테스트 커버리지 도구를 사용하여 아직 테스트가 없는 애플리케이션의 주요 부분을 찾아내고 거기서부터 시작하세요.
자동 테스트
지속적 배포의 가장 중요한 종속성은 자동 테스트입니다. 실제로 지속적 통합, 제공 및 배포의 전체 체인은 자동 테스트에 달려 있습니다. 자동 테스트는 새 코드 도입 시 회귀를 방지하는 데 사용되며, 새 코드 변경 사항에 대한 수동 테스트를 대체할 수 있습니다.
롤링 배포
지속적 배포와 지속적 제공을 구분하는 특징은 라이브 환경에서 새 코드를 활성화하는 자동화 단계입니다. 지속적 배포 파이프라인에서는 버그나 잘못된 변경 사항이 배포되는 경우 배포를 취소할 수 있어야 합니다. 그린-블루(Green-Blue) 배포와 같은 자동 롤링 배포 도구는 적절한 지속적 배포를 위한 필수 조건입니다.
모니터링 및 알림
강력한 지속적 배포 파이프라인을 위해서는 실시간 모니터링과 알림이 있어야 합니다. 모니터링 및 알림을 사용하면 전체 시스템의 상태와 새 코드 배포의 전후 상태를 볼 수 있습니다. 또한 알림을 사용하여 롤링 배포 '실행 취소'를 트리거하여 실패한 배포를 되돌릴 수 있습니다.
지속적 배포 모범 사례
지속적 배포 파이프라인을 구축한 후 성과를 얻기 위해서는 엔지니어링 팀의 지속적인 유지 관리와 참여가 필요합니다. 엔지니어링 팀은 다음과 같은 모범 사례와 행동을 활용해 지속적 배포 파이프라인을 최대한 활용할 수 있습니다.
테스트 중심 개발
테스트 기반 개발은 개발을 시작하기 전에 새 소프트웨어 기능의 동작 사양을 정의하는 관행입니다. 사양이 정의되면 개발자는 사양에 맞는 자동 테스트를 작성합니다. 마지막으로 테스트 케이스와 사양을 충족하는 실제 산출물 코드가 작성됩니다. 이 프로세스를 통해 모든 새 코드에 자동 테스트가 먼저 적용됩니다. 다른 방법은 코드를 먼저 제공한 다음 테스트 커버리지를 만드는 것입니다. 그러면 예상된 사양 동작과 생성된 코드 사이에 차이가 생길 가능성이 있습니다.
단일 배포 방법
지속적 배포 파이프라인을 갖춘 후에는 이를 유일한 배포 방법으로 사용하는 것이 중요합니다. 개발자는 프로덕션이나 라이브 환경에 코드를 수동으로 복사하고 편집해서는 안 됩니다. CD 파이프라인 외부에서 수동으로 변경하면 배포 기록이 동기화되지 않아 CD 흐름이 중단됩니다.
컨테이너화
소프트웨어 애플리케이션을 컨테이너화하면 배포된 모든 컴퓨터에서 동일하게 동작합니다. 그러면 소프트웨어가 컴퓨터마다 다르게 동작하는 모든 문제가 해결됩니다. 컨테이너는 CD 파이프라인의 일부로 통합할 수 있으므로 코드가 개발자 컴퓨터에서도 자동 테스트와 프로덕션 배포에서처럼 동일하게 동작합니다.
요약하자면...
지속적 배포는 오늘날의 엔지니어링 조직에 강력한 도구가 될 수 있습니다. 배포는 통합, 제공, 배포로 구성된 전체 '지속적 파이프라인'의 마지막 단계입니다. 진정한 지속적 배포의 경험은 코드가 프로덕션에 배포되고 정확성 테스트를 거쳐 틀렸을 때는 자동으로 되돌리고 맞으면 수락하는 수준까지 자동화하는 것입니다.
지속적 제공을 실제로 적용하려면 DevOps CI/CD 자습서를 확인하세요. Jira를 사용한 Atlassian Open DevOps 및 타사 통합에 대해 자세히 알아볼 수 있습니다.
이 문서 공유
다음 토픽
여러분께 도움을 드릴 자료를 추천합니다.
이러한 리소스에 책갈피를 지정하여 DevOps 팀의 유형에 대해 알아보거나 Atlassian에서 DevOps에 대한 지속적인 업데이트를 확인하세요.
DevOps 커뮤니티
블로그 읽기
