지속적 배포(CD)란?

통합 및 배포 프로세스를 완전히 수동으로 진행하면서 코드를 동결하고 테스트 전략에 모두가 매달려 출시일에 회사 전체가 숨을 죽이고 걱정하는 상황이라면 특별할 것 없이 매시간 배포를 수행할 수 있다는 것은 꿈처럼 느껴질 것입니다.

그러나 현실은 Netflix, Etsy 및 Amazon과 같은 유명 기업부터 시장에 발 맞추기 위해 애쓰는 소규모 기업에 이르기까지 수 많은 조직이 이 접근 방식으로 전환하고 있다는 것입니다. 이들 기업은 지속적 배포 시스템을 채택하여 릴리스 기간을 몇 주 또는 몇 달에서 몇 시간으로 단축하고 있습니다. 점점 더 많은 산업 분야에서 기능을 빠르게 제공하고 피드백에 신속하게 대응할 수 있는 능력은 필수적 자질로 자리잡고 있습니다.

지속적 통합과 전달의 연장선에 있는 지속적 배포는 완전 자동화된 테스트 및 빌드 배포 프로세스를 통해 빠른 속도에서도 품질이 떨어지지 않도록 보장합니다. 그러나 지속적 배포를 효과적으로 구현하려면 견고한 기반 그 이상이 필요합니다.

지속적 배포 시스템을 구현할 방법을 계획할 때 핵심적으로 고려해야 할 점은 변경이 릴리스되는 방식입니다. 온라인 서비스가 자주 중단되지 않도록 서버를 오프라인으로 전환하는 대신 롤아웃 업데이트를 선택하는 외에도 롤아웃을 자동 테스트 프로세스의 일부로 만들 수 있습니다.

카나리 배포를 통해 프로덕션 환경에서 자신도 모르는 사이에 테스터가 되는 소수의 사용자에게 업데이트된 코드를 배포할 수 있습니다. 행동 및 사용 메트릭을 모니터링하여 새 릴리스를 더 광범위하게 배포하기 전에 여기에 새로운 오류가 도입되었는지 여부를 확인할 수 있습니다.

일부 회사는 전체 메트릭을 기준선과 자동으로 비교하는 카나리 신뢰도 점수를 이용해 자동화 수준을 더욱 높입니다. 롤아웃은 점수가 지정된 임곗값을 초과하는 경우에만 자동으로 계속되며, 메트릭 분석은 잠재적 문제를 추가적으로 조사하기 위한 시작점을 제공합니다.

블루/그린 빌드 배포 프로세스는 지속적 배포 시스템을 구현하는 조직이 일반적으로 채택하는 기술로, 변경 사항이 예상한 대로 작동한다는 확신이 들 때까지 이전 코드를 온라인 상태로 유지하여 문제 발생시 릴리스를 쉽게 롤백할 수 있습니다. 필요한 경우 블루/그린 롤아웃으로 초기 카나리 배포를 진행할 수 있습니다.

블루/그린 배포를 실행하거나 직접 대체물을 롤아웃하는 모든 경우에 릴리스 프로세스에서 걸러내지 못한 버그에 신속하게 대응할 수 있으려면 프로덕션 시스템의 상태를 모니터링하는 것이 중요합니다.

디스크 공간 및 CPU 사용량부터 요청 또는 트랜잭션 수에 이르기까지 시스템 상태를 나타내는 특정 메트릭을 주시하고 이를 기준선과 비교하면 상황이 의도한 것과 다를 때 조기 경고를 받을 수 있습니다. 그런 다음 변경 사항을 롤백할지, 파이프라인을 통해 수정 사항을 적용하여 롤포워드할지 결정할 수 있습니다.

지속적 배포의 시류에 뛰어들기 전에 CD를 채택할 때 일반적으로 발생하는 몇 가지 문제를 잠시 고려해 볼 필요가 있습니다.

소프트웨어 개발 라이프사이클에 단순히 코드 변경만 관련된 것은 아닙니다. 사용자 조사, 제품 마케팅, 상호 작용 디자인, 문서화, 상업, 법률 및 지원 팀 모두가 해야 할 역할이 있습니다.

릴리스 과정에서 이해 관계자의 요구 사항을 이해하기 위한 참여의 토대를 마련하지 않는다면 그들에게 지속적 배포로의 전환은 통제되지 않은 개발처럼 느껴질 수 있습니다. 이로 인해 수작업 검토 단계가 도입되어 프로세스 속도가 느려지거나, 심지어 전체 지속적 배포 시스템이 실패한 실험으로 거부될 수 있습니다.

협업의 문화를 만드는 것이 필수적입니다. 예를 들어 설계, 보안 문제, 용어 또는 규정 준수에 대한 의견을 초기에 통합할 수 있도록 개발 프로세스 전반에 걸쳐 다른 팀을 참여시키 등의 간단한 피드백 순환을 통해 소프트웨어 개발 라이프사이클을 더 효율적으로 만들 수 있습니다. 의견을 수렴하는 것만큼이나 중요한 것은 언제 무엇을 릴리스하는지 명확히 알 수 있도록 하는 것입니다. 대시보드 및 알림을 통해 정보를 전달하는 지속적 빌드 배포 도구인 CI 서버의 도움으로 이해 관계자들에게 지속적으로 정보를 제공할 수 있습니다.

때로는 무엇이 예상되는지를 알려주는 것만으로 충분하지 않습니다. 보다 큰 기능을 작업 중이거나 릴리스 시기를 관리해야 하는 경우, 테스트를 통과하는 즉시 각 커밋을 라이브로 배포하는 것은 이상적이지 않습니다.

기능 플래그는 프로덕션에서 코드의 가시성을 제어하기 위한 방법 중 하나이며, 코드가 라이브 상태이므로 예기치 않은 오류를 모니터링할 수 있다는 장점이 있습니다. 또 다른 방식은 프로덕션으로 자동 푸시되지 않는 별도의 파이프라인에 배포된 전용 브랜치를 사용하여 필요에 맞게 지속적 전달과 지속적 배포를 결합하는 것입니다.

지속적 배포를 올바르게 수행하면 더 원활하게 사용자에게 소프트웨어를 배포할 수 있습니다. 지속적 배포 성공 사례를 따르면 프로세스를 간소화하고 더 나은 결과를 얻을 수 있습니다. 예를 들어, 문제의 징후가 있는지 파이프라인을 정기적으로 모니터링하고 평가하는 것이 중요합니다. 효과적인 CI/CD 파이프라인을 구축하기 위해 팀 전체를 참여시키는 것 또한 필요합니다.

이 둘을 혼동하기 쉽지만 지속적 배포와 지속적 전달은 둘 모두 CI/CD 파이프라인의 CD 측면에서 구분이 되는 부분들입니다. While continuous delivery is focused on automating the steps required to deliver the software to users (for example, by automating builds, test automation, etc.), continuous deployment is a logical continuation of the process, automating the release of the software to end users provided that all necessary criteria are met.

지속적 배포는 품질 저하 없이 사용자에게 기능을 빠르게 제공하기 위해 자동화 사용을 극대화합니다. 이 DevOps 방식에서 기본이 되는 것은 정기적이고 신속한 피드백입니다. 자동화된 테스트, 프로덕션 모니터링, 다른 직무자와의 협업 및 사용자 행동 모두가 소프트웨어 개발 프로세스에 대한 피드백을 제공합니다. 더 세분화된 단위로 작업하고 자주 릴리스하면 피드백을 기반으로 계속 조정하고 전달하는 내용을 지속적으로 개선할 수 있습니다.