Continuous delivery

Contents

Continuous delivery(CD 혹은 CDE, 지속적인 전달)는 팀이 짧은 주기로 소프트웨어를 생산하는 방식으로 소프트웨어를 안정적으로 출시할 수 있도록하는 엔지니어링 방식이다. 빠른 속도와 잦은 빈도로 소프트웨어를 개발하고, 테스트를 끝내고 출시하는게 목표다. 이 접근법을 이용하면 응용 프로그램을 보다 점진적으로 개선하고 변경 사항을 업데이트 할 수 있게 된다. 소프트웨어의 기능이 변경되면 리스크가 따르기 마련인데, 잦은 사이클로 테스트와 출시를 반복하기 때문에 리스크를 최소화 할 수 있다. CD를 위해서는 간단하고 반복가능한 소프트웨어 배포 프로세스를 개발해야 한다.

DevOps와 CD는 그 의미가 비슷하고 겹치는 경우가 많은데, 두 가지 다른 개념이 있다. DevOps는 개발자, 운영자, QA, 보안 등 다양한 팀의 협업과 소프트웨어 개발&전달&출시 프로세스를 자동화하는 광범위한 문화적 변화에 무게중심이 가 있다. 반면에 CD는 전달측면을 자동화 하는 좀더 세분화되고 기술적인 실행을 중요시한다. 결과적으로 DevOps 활동의 실질적인 실행 측면에서 CD가 수행 될 수 있으며, CD의 수행결과가 DevOps 활동으로 이어질 수 있다.

지속적인 전달은 메뉴얼한 릴리즈 수행에 따라서 언제든지 배포할 수 있는 시스템이다. 지속적인 배치를 위해서는 지속적인 전달이 가능해야 한다.

코드가 릴리즈 되기 전까지, 빌드/유닛테스트, 자동화된 통합테스트, 사용자 테스트 등을 거쳐야 한다. 이 모든 과정을 통과해야지만 코드가 릴리즈 될 수 있다. 이러한 과정 특히, 빌드와 테스트 그리고 레포팅 과정은 모두 자동화해야 한다.

CD는 언제든지 고객에게 소프트웨어가 전달될 수 있음을 이해하는 것이 중요하다. 긴주기로 소프트웨어를 전달하고 있는 개발자 혹은 팀이라면 CD 환경에 적응하기 위해서 사고방식/개발 툴을 변경해야 할 수 있다.

예를들어 토글 같은 기능을둬서 사용준비가 되지 않은 코드를 사용 할 수 없게 할 수 있는데, 이는 특정 기능의 개발이 끝나지 않았더라도, 다른 준비된 기능은 빠르게 전달하도록 할 수 있다. NoSQL을 사용하면 데이터 마이그레이션 및 스키마 변경 단계를 생략 할 수 있다. 코드 브랜치 전략도 수정해야 할 수 있다. CD의 경우 여러 개의 긴 코드 브랜치를 실행하는 방식을 지양한다.

배포 파이프라인을 구축해서 CD가 가능하도록 해야 한다. 배포 파이프라인의 목적은 가시성, 피드백, 지속적 배포를 충족하는데 있다.

• 가시성(visibility) : 코드 변경, 테스트 결과, 배포의 각 단계가 팀의 모든 구성원들에게 공개되야 한다.
• 피드백 : 팀 구성원이 빠르게 문제를 파악 할 수 있도록 피드백 시스템을 만들어야 한다.
• 지속적인 배포 : 완전히 자동화된 프로세스를 통해서 모든 버전의 소프트웨어를 각 환경에 배포 릴리스 할 수 있어야 한다.

CD는 소스 버전 컨트롤부터 릴리즈까지의 과정을 자동화할 수 있어야 한다. 이 과정의 일부 혹은 전부의 자동화를 수행하기 위한 다양한 툴들이 있다. 여기에는 CI(continuous integration), build automation, application lifecycle management 영역의 툴들이 필요하다.

CD를 효과적으로 수행하기 위해서, 애플리케이션들은 deployability, modifiability, testability와 같은 아키텍처 중요 요구사항(Architecturally significant requirements - ASRs)을 충족해야 한다. 쉽게 배포되고, 쉽게 수정되고, 쉽게 테스트 할 수 있도록 개발해야 한다는 의미가 되겠다.

마이크로서비스는 종종 CD를 위한 아키텍처로 사용된다. MSA(Micro service architecture)를 사용하면 소프트웨어의 deployability, modifiability 를 높일 수 있다. 다만 소프트웨어가 분산되면서 testability는 떨어질 수 있으므로 주의가 필요하다. MSA는 점진적 기능 변경을 위해서 보다 짧은 개발주기, 쉬운 기술의 선택, 쉬운 언어, 쉬운 라이브러리의 사용을 권장한다.

Jez Humble과 David Farley가 저술한 CD Book이 CD 용어를 대중화 시켰다. 지금도 계속 발전하고 있으며, Yahoo.com, Amazon.com, Facebook, Google, Paddy Power, Wells Fargo 등의 기업들이 이러한 접근방법을 사용하고 있다.

CD의 알려진 장점은 아래와 같다.

• 출시 시간 단축 : CD를 이용해서 조직은 새로운 소프트웨어를 신속하게 고객에게 전달 할 수 있다. 이 기능은 회사가 경쟁에서 앞서나가는데 도움이 된다.
• 적합핮 제품 개발 : 자주 출시되면 애플리케이션 개발팀은 사용자 피드백을 신속하게 얻을 수 있다. 이를 통해서 유용한 기능의 개발에 리소스를 집중시킬 수 있다.
• 향상된 생산성 : 자동화를 통해 개발자, 테스트, 운영자 모두 상당한 시간을 절약 할 수 있다 * 신뢰성 향상 : 릴리즈와 관련된 위험이 크게 줄어든다. CD를 사용하면 프러덕션 환경에 배포하기 전에 배포프로세스 및 스크립트를 반복적으로 테스트 할 수 있다. 릴리즈 전에 대부분의 오류를 발견 할 수 있다. 자주 릴리즈 하면 코드 변경수가 줄어들고, 문제가 발생할 확률이 줄어들며, 문제가 발생하는 범위가 특정된다. 이렇게 하면 문제를 찾아서 해결하는데 걸리는 시간을 줄일 수 있다.
• 제품 품질의 향상 : 버그와 사고가 크게 줄어들었다.
• 고객 만족도 향상

아래와 같은 단점들도 보고됐다.

• 고객 환경 : 어떤 고객들은 빈번한 릴리즈를 좋아하지 않는다.
• 도메인 제한 : 텔레콤과 의료 같은 일부 영역에서는 광범위한 테스트 때문에 CD를 적용하기가 쉽지 않다.
• 테스트 자동화의 부족 : 테스트 자동화가 부족하면 개발자의 확신도 부족해진다.
• 환경의 차이 : 개발, 테스트에서 사용하는 다양한 환경으로 인해, 감지되지 않은 문제가 운영단계에서 발생 할 수 있다.
• 테스터의 필요 : 자동화를 통해서 모든 품질을 검사 할 수는 없다. 사람을 투입해야 하는데, CD 파이프라인에서 병목구간이 될 수 있다.

• Continuous delivery - wikipedia