지속적 제공(continuous-delivery)이란 무엇인가요?

통합 툴박스 프로비저닝 시 지속적 제공의 이점:

• 지속적인 테스트 및 개발을 통해 배포 시간 단축
  
  
• 기존 소프트웨어 개발과 관련된 비용 절감
  
  
• 프로젝트 규모에 따라 소프트웨어 개발 규모 조정
  
  
• 개발 주기의 각 단계에 자동으로 코드 배포

지속적 제공을 활용할 때 다음과 같은 모범 사례를 고려하는 것이 좋습니다.

• 모든 변경 사항을 릴리스할 수 있도록 준비: 지속적 제공을 활용하여 모든 변경 사항을 릴리스하도록 준비하는 경우, 감사 목적으로 사용자 문서, 운영 런북 및 변경 사항에 관한 정보를 포함해야 합니다.
  
  
• 트렁크 기반 개발 수용: 지속적 제공은 지속적 통합을 기반으로 합니다. 모든 변경 사항을 함께 구축, 테스트 및 배포하여 가장 빠른 피드백을 받을 수 있도록 가능한 한 통합을 지연시키는 부분을 피하세요.
  
  
• 자동화된 파이프라인을 통해 제공: 지속적 제공을 성공적으로 구현하려면 모든 코드 릴리스가 일관된 방식으로 테스트 및 프로덕션 환경으로 이동할 수 있도록 잘 구성된 자동화된 제공 파이프라인이 필요합니다.
  
  
• 최대한 자동화 구현: 지속적 제공을 구현할 때는 소프트웨어 개발 라이프사이클에서 가능한 한 많은 프로세스를 자동화해야 합니다. 이러한 자동화를 통해 코드 빌드 및 배포뿐만 아니라 새로운 개발 환경 생성을 위한 안정적이고 신뢰할 수 있는 제공 파이프라인을 구축할 수 있습니다.
  
  
• 중단 시간 방지 목표: 지속적 제공으로 자주 업데이트를 진행하면서 애플리케이션 가용성을 보장하려면 새 함수를 프로덕션 환경에 적용할 때 퍼블릭 실행 애플리케이션 인스턴스에 배포하기 전에 먼저 유효성을 검사해야 합니다.
  
  
• 테스트 단위로 릴리스: 시스템의 두 부분을 함께 테스트해야 하는 경우, 두 부분을 함께 릴리스하여 시스템 부품이 호환되는지 확인해야 합니다. 릴리스 자동화 툴은 이러한 유형의 제공을 조정하는 데 유용합니다. 아니면 완전히 분리하는 방법도 있습니다.

지속적 제공의 이점을 활용하려면 지속적 탐색, 지속적 통합, 지속적 배포 및 온디맨드 릴리스와 같은 지속적 프레임워크의 다른 요소가 필요합니다.

지속적 제공 파이프라인 단계를 사용하는 경우, 단계 내의 실행 단위인 별도의 작업으로 나누어야 합니다.

• 빌드 작업: 빌드 작업에서 프로젝트를 컴파일하여 배포를 준비합니다. 여기서 빌드 아카이브 디렉토리로 보낼 수 있는 아티팩트를 생성합니다.
  
  
• 작업 배포: URL에서 액세스할 수 있는 앱으로 프로젝트를 지속적 제공 파이프라인에 업로드합니다. 프로젝트를 배포한 후에는 대시보드에서 프로젝트를 확인할 수 있습니다.
  
  
• 테스트 작업: 빌드 전후에 테스트 작업을 맞춤형으로 설정하여 포함하고, 타사 테스트 서비스를 사용하여 단위 테스트 또는 기능 테스트를 기반으로 작업을 배포합니다.

지속적 제공 파이프라인은 개발 팀이 다음 작업을 수행하는 데 도움이 될 수 있습니다.

• 빌드, 단위 테스트 및 배포 자동화
  
  
• Git 리포지토리, 문제 추적 및 웹 기반 IDE(통합 개발 환경)를 사용하여 코드를 편집하고 푸시합니다.
  
  
• 서비스, 오픈 소스 툴 및 타사 툴로 앱을 빌드, 배포 및 관리할 수 있는 통합 DevOps 툴박스 구축
  
  
• 원하는 곳에서 코드를 편집하여 IDE를 사용해 소스 제어 작업 생성, 편집, 실행, 디버그 및 완료
  
  
• 자동화된 파이프라인을 사용하여 반복 가능한 방식으로 빌드, 테스트 및 배포를 지속적으로 제공
  
  
• 빌드 상태, 보안 스캔 결과, 코드 커버리지, 테스트 커버리지를 파악하여 품질을 개선함으로써 다음 환경으로 앱을 승격할지 여부를 평가(승격 전에 자동으로 품질을 보장하는 정책 게이트 활용)

지속적 배포는 지속적인 배포 파이프라인의 일부일 수 있습니다. 구체적으로 살펴보면, 지속적 제공은 개발 라이프사이클(제공 라이프사이클이라고도 함)을 통해 코드가 자동으로 이동하는 것을 말합니다. 지속적 배포는 자동화된 필수 테스트를 통과하면 해당 코드가 프로덕션으로 자동 이동하는 것을 말합니다.

제공 파이프라인의 일부로 지속적 배포를 포함할지 여부는 비즈니스 요구 사항에 따라 달라집니다. 기업에서 제공 팀이 신규 또는 업데이트된 소프트웨어를 반복적으로, 안정적으로 또는 가능한 한 빨리 프로덕션에 릴리스해야 하거나, 솔루션에 여러 종속성이 존재하는 경우 지속적 배포를 통해 이점을 얻을 수 있습니다.

지속적 배포와 지속적 제공의 차이점에 관한 자세한 내용은 다음 동영상에서 확인하세요.

지속적 제공 툴을 사용하면 오픈 소스 툴을 활용하여 애플리케이션을 구축, 배포 및 관리할 수 있습니다. 툴 세트를 통합하면 개발 팀뿐만 아니라 운영 팀에서도 반복 가능하고 관리 가능한 작업을 생성할 수 있습니다.

툴박스에는 현재 사용 중인 클라우드 서비스, 오픈 소스 툴, 타사 툴은 물론 다음과 같은 지속적 제공 툴도 있을 수 있습니다.

• 구축 및 배포 자동화를 위한 반복 가능한 템플릿: 기업의 앱 중 하나에서 작동한다면 다른 앱에서도 작동합니다. 모든 팀이 직접 구성하기 위해 어려움을 겪지 않도록 하세요.
  
  
• 파이프라인: 파이프라인이 있으면 변경 사항을 푸시할 때 자동으로 구축하고, 클라우드에 배포하며, 구축 및 배포를 툴 체인에 통합하고, 툴 체인 전반에서 배포를 관리할 수 있습니다.
  
  
• 팀 공동 작업, 계획, 소스 코드 관리 및 테스트를 위한 툴
  
  
• 팀이 빠르게 작업하고 있는 부분과 정체된 부분을 파악하여 '더 지속적으로' 개선할 수 있는 가이드를 제공하는 인스트루먼테이션

강력한 지속적 제공 파이프라인을 위해 사용할 수 있는 오픈 소스 지속적 제공 툴로는 Jenkins, Concourse CI, Spinnaker, Travis CI, GoCD 및 GitLab CI가 있습니다.

이전에는 소프트웨어를 한 번만 출시한 다음 업데이트했습니다. 그러면 소프트웨어가 고객의 요구 사항을 충족했는지 처음과 마지막에만 알아볼 수 있습니다.

애자일은 지속적 제공 일정에 따라 짧은 반복 작업으로 소프트웨어를 제작하는 방법입니다. 오늘날의 애자일 지속적 제공 프로세스를 통해 정의된 각 기능을 사용할 수 있게 되면 고객에게 코드를 릴리스할 수 있습니다. 민첩한 개발과 지속적 제공은 프로덕션 준비가 완료되자마자 고객에게 기능을 제공하는 열쇠입니다. 목표는 각 기능이 파이프라인을 빠져나갈 때 릴리스할 수 있도록 준비하는 것입니다.

지난 수십 년 동안 소프트웨어 개발은 표준 폭포수형 개념에서 더 효율적인 애자일 방법론으로 이동하면서 상당한 변화를 겪었습니다. 적응하려면 애자일, DevOps 및 지속적 제공에 중점을 둔 접근 방식으로 전환해야 합니다. 지속적인 제공 파이프라인의 일부로서 이러한 집중적인 프로세스를 통해 더욱 안정적인 고품질 소프트웨어 릴리스 및 업데이트가 가능해졌습니다.

애자일 개발을 통해 더 빠르고 규모가 더 작은 소프트웨어 릴리스를 구현하면 소프트웨어 개발의 개별 단계에 더 집중하게 됩니다. 또한 이 방식을 취하면 개발 팀과 운영 팀이 하나로 긴밀하게 통합되어 코딩부터 테스트, 배포, 지원에 이르는 소프트웨어 개발 라이프사이클 전체를 다루기 때문에, DevOps가 '더 큰 그림'과 문화적 변화에 집중할 수 있습니다.