지속적 전달이란?

DevOps의 핵심은 사고방식의 변화입니다. DevOps 관점에서 소프트웨어 개발 프로세스는 한 방향으로 이동하며 요구 사항, 코드 및 보고서가 한 팀에서 다른 팀으로, 선형적 방식으로 전달되는 컨베이어 벨트가 아닙니다. 대신 DevOps는 짧고 반복적인 주기로 협업과 신속한 피드백을 지원합니다.

완료에 대한 정의를 변경하면 이러한 사고방식을 적용하는 데 도움이 될 수 있습니다. 체인의 다음 팀으로 코드를 넘기면 우리 팀의 역할이 완료된 것으로 간주하는 대신 신규 기능이나 코드 변경은 라이브 릴리스 후에만 완료된 것으로 생각해야 합니다. 파이프라인의 어느 단계에서든 문제가 발견되면 해당 피드백을 즉시 전달하고 협력하여 수정할 때 승인을 위해 변경 보드를 거쳐야 하는 긴 보고서보다 더 빠르게 문제를 해결할 수 있습니다. 이것이 지속적 전달의 핵심입니다.

소프트웨어 개발 수명 주기의 일부가 아닌 전체적인 개발 수명 주기를 살펴봄으로써 사용자에게 소프트웨어를 제공하는 데 필요한 사항을 더 잘 이해하고 다른 관련 팀과 다양한 커뮤니케이션 라인을 열 수 있습니다.

지속적인 전달은 전달 프로세스를 지연하는 문제점을 파악하고, 자동화된 파이프라인을 구축하여 더욱 빠르고 안정적인 릴리스 과정을 만들어 언제나 릴리스에 대비하는 것을 의미합니다. 파이프라인이 준비되면 명령어 하나만으로 적합한 빌드를 라이브 배포할 수 있어야 합니다.

지속적 통합은 최소한 매일 커밋되는 코드 변경과 개발자에게 신속한 피드백을 제공하는 자동화된 빌드 및 테스트 프로세스를 통해 이를 위한 기반을 제시합니다. 빌드 또는 테스트 실패 시 해당 문제 해결이 모두의 우선순위입니다.

버그를 조기에 발견하면 코드를 명확히 기억하는 상태에서 수정할 수 있으며, 부적절한 코드를 기반으로 기능이 추가되는 것을 방지하므로 향후 코드를 다시 살펴볼 필요가 없습니다. 지속적인 전달을 활용하면 CI 프로세스의 최신 변경 사항이 포함된 빌드가 일련의 사전 프로덕션 환경을 통해 다음 단계에 자동으로 넘어갑니다. 프로덕션으로의 최종 푸시는 수동으로 트리거되지만, 여전히 스크립팅된 프로세스를 따르므로 쉽게 반복하여 필요한 만큼 여러 번 릴리스할 수 있습니다.

CI/CD 파이프라인 구축은 릴리스 프로세스의 다양한 관계자와 협력할 좋은 기회이므로 파이프라인 설계 시 여러 관계자의 니즈를 고려할 수 있습니다. 자동화된 테스트를 설계하면서 이미 QA 팀 동료와 협력하고 있을 것으로 생각합니다.

적절한 테스트 환경(최대한 프로덕션에 가까운 환경)에서 수동 탐색 테스트 단계를 추가하면 예상치 못한 오류를 식별할 수 있습니다(이후 자동화된 테스트로 오류 해결 가능). 이것이 지속적 전달을 위한 중요한 단계입니다.

정보보안 또는 사이버보안 팀은 보안 감사를 실행하는 데 소요되는 시간과 감사 이후의 긴 보고서로 인해 빈번한 릴리스의 장애물로 간주되는 경우가 많습니다. DevSecOps 접근 방식을 활용하면 보안 요구 사항을 파이프라인에 통합하는 데 도움이 됩니다.

정확한 빌드 단계, 환경 및 테스트의 필요성은 소프트웨어 아키텍처와 조직의 우선순위에 따라 달라집니다. 마이크로 서비스를 기반으로 시스템을 구축하는 경우 정교한 통합 및 엔드투엔드 테스트를 위해 개별 테스트를 결합하기 앞서 아키텍처를 활용해 개별 서비스의 테스트를 동시에 실행할 수 있습니다.

파이프라인을 통해 발생하는 모든 버그 수정을 처리하기에 수동 탐색 테스트는 과하게 느껴질 수 있습니다. 이런 경우 변경 유형에 따라 선택적 단계 또는 대체 파이프라인을 설정하는 것이 지속전 전달에 보다 효율적일 수 있습니다.

각 단계에서 실행할 테스트를 포함한 파이프라인의 단계가 결정되면 프로세스를 스크립팅하여 안정적이고 반복 가능한지 확인해야 합니다. 비일관성을 방지하려면 CI 단계의 동일한 빌드 아티팩트를 각각의 사전 프로덕션 환경과 프로덕션 자체에 배포해야 합니다.

이상적으로는 새 빌드마다 테스트 환경을 수정해야 합니다. 코드로서 인프라 방식으로 컨테이너를 사용하면 이 단계를 스크립팅하여 필요에 따라 새로운 환경을 해체하고 생성할 수 있습니다.

지원, 영업 또는 마케팅팀이 새로운 기능을 익힐 수 있는 스테이징 환경이 파이프라인에 포함된 경우 진행 중인 작업에 방해가 되지 않도록 해당 환경의 새 빌드 업데이트 시기를 수동으로 제어하는 것이 좋습니다. 최종 라이브 릴리스와 마찬가지로 배포를 스크립팅하여 프로세스를 빠르고 일관성 있게 유지할 수 있습니다.

지속적인 전달을 통해 품질 저하 없는 더 빠른 릴리스를 기대할 수 있지만 이를 실현하려면 조직의 여러 부분이 협력해야 합니다.

협업은 보다 효과적인 작업에 도움이 되므로 사일로의 제거는 단기적으로 해결해야 할 과제이지만 장기적으로 이점이 될 수 있습니다.

지속적인 전달의 구현은 시간 투자가 필요하며 어렵게 느껴질 수 있습니다. 반복적 접근 방식을 활용하고 점진적으로 프로세스를 구축함으로써 구현 과정을 더 수월하게 관리하고, 고위 관계자에게 지속적인 전달의 이점을 입증할 수 있습니다. 빌드 및 테스트 시간의 측정 기준을 수집하여 이를 수동 절차와 비교하는 것은 결함률과 마찬가지로 투자 수익을 보여주는 간단한 방법입니다.

지속적인 전달의 가치 측정은 인프라 요구 사항 계획 시 유용할 수 있습니다. 릴리스 프로세스를 확장할 때 여러 빌드와 테스트를 동시에 실행해야 할 수 있으며 지원되는 시스템이 제한 요소가 될 수 있습니다. 파이프라인 성능 최적화를 수행한 후 필요에 따라 확장할 수 있도록 클라우드 호스팅 인프라로 이전을 고려해 보십시오.

CI/CD 파이프라인 빌드는 초기에 수고가 많이 드는 어려운 작업처럼 보일 수 있습니다. 하지만 제대로만 수행한다면 CI/CD를 통해 소프트웨어 제공 프로세스를 1/10의 시간만에 완료할 수 있습니다. 올바른 프로세스를 구축하려면 몇 가지 CD 모범 사례를 따라야 합니다.

지속적 전달은 소프트웨어를 프로덕션으로 진행시키는 데 필요한 다양한 단계를 자동화하는 프로세스입니다. 그러나 소프트웨어 릴리스를 완전히 자동화하는 것은 아니므로 지속적 배포가 필요합니다. 지속적 전달과 지속적 배포는 동일한 CI/CD 프로세스의 서로 다른 부분으로 생각할 수 있습니다.

지속적 전달과 지속적 배포에 대해 자세히 알아보기

지속적인 전달을 사용하면 소프트웨어를 보다 간편하고 빠르게 릴리스할 수 있어 프로덕션으로 배포 빈도를 높일 수 있습니다. 대규모 분기별 릴리스나 연간 릴리스 대신 소규모 업데이트가 자주 제공됩니다. 따라서 사용자는 신규 기능과 버그 수정을 사용자에게 더 빠르게 받아볼 수 있으며 개발자는 소프트웨어의 사용 방식을 확인하고 그에 따라 계획을 조정할 수 있습니다.

릴리스 프로세스의 마지막 단계에 대한 제어를 유지하려는 조직이 있는 한편 CI/CD 파이프라인의 논리적 귀결은 지속적 배포라는 관행을 활용한 라이브 릴리스 자동화라고 생각하는 조직도 있습니다.