지속적 제공을 활용할 경우 고려해야 할 모범사례는 다음과 같습니다.

• 모든 변경 사항을 릴리스 가능하게 만듦: 지속적 제공을 활용하여 모든 변경 사항을 릴리스 가능하게 만들려면, 감사 목적으로 사용자 문서, 운영 런북, 변경 사항에 대한 정보를 반드시 포함해야 합니다.
  
  
• 트렁크 기반 개발(trunk-based development) 수용: 지속적 제공은 지속적 통합을 기반으로 구축됩니다. 모든 변경 사항이 가장 빠른 피드백을 얻기 위해 함께 구축, 테스트, 배포될 수 있도록 최대한 통합을 지연하는 브랜치(branch)를 피해야 합니다.
  
  
• 자동화된 파이프라인을 통해 제공: 지속적 제공을 성공적으로 구현하려면, 모든 코드 릴리스가 일관적으로 테스트 및 프로덕션 환경으로 이동하도록 하기 위해 잘 구성되고 자동화된 제공 파이프라인이 필요합니다.
  
  
• 최대한 자동화하기: 지속적 제공을 활용하는 경우, 단지 코드 빌드와 배포뿐만 아니라 새로운 개발 환경의 조성을 위해서도 소프트웨어 개발 라이프사이클에서 최대한 많은 프로세스를 자동화하여 신뢰할 수 있는 우수한 제공 파이프라인을 만들어야 합니다.
  
  
• 다운타임이 전혀 없는 상태를 목표로 설정: 새 기능을 프로덕션 단계로 푸시할 때 자주 지속적 제공 업데이트를 수행하면서 애플리케이션 가용성을 유지하려면, 공개적으로 실행되는 애플리케이션 인스턴스에 배포하기 전에 이를 먼저 검증해야 합니다.
  
  
• 세분화된 테스트를 통해 릴리스: 시스템의 두 부분을 함께 테스트해야 하는 경우, 시스템의 이 부분들이 호환되는지 알 수 있도록 이들을 함께 릴리스해야 합니다. 릴리스 자동화 툴은 이러한 종류의 제공을 잘 조율합니다. 또는, 완전히 디커플링합니다.

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

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

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

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

• 빌드, 유닛 테스트 및 배포 자동화
  
  
• Git 리포지토리, 문제 추적 및 웹 기반 IDE(integrated development environment)를 사용하여 코드를 편집하고 푸시
  
  
• 서비스, 오픈소스 툴, 타사 툴로 앱을 빌드, 배포, 관리하기 위해 통합된 DevOps 툴박스를 만듦
  
  
• IDE를 사용하여 소스 컨트롤 작업을 생성, 편집, 실행, 디버깅, 완료하기 위해 원하는 곳 어디에서나 코드를 편집
  
  
• 자동화된 파이프라인을 사용하여 반복 가능한 방식으로 지속적으로 빌드, 테스트, 배포를 제공
  
  
• (승급 전에 품질을 확인하기 위해 정책 게이트를 통해) 앱을 다음 환경으로 승급해도 되는지 평가할 수 있도록 빌드 상태, 보안 스캔 결과, 코드 적용 범위 및 테스트 적용 범위를 이해하여 품질 향상

지속적 배포는 지속적 제공 파이프라인의 일부일 수 있습니다. 구체적으로 말하면, 지속적 제공은 개발 라이프사이클(때때로 제공 라이프사이클이라고도 부름)을 통해 코드가 자동으로 이동하는 것이며, 지속적 배포는 코드가 자동화된 필수 테스트를 통과한 후 이러한 코드가 프로덕션 단계로 자동으로 이동하는 것입니다.

지속적 배포를 제공 파이프라인에 포함할지 여부는 비즈니스 요구 사항에 따라 달라집니다. 기업에서 제공 팀이 새로운 소프트웨어나 업데이트된 소프트웨어를 반복적으로, 안정적으로 또는 최대한 빨리 프로덕션 단계로 릴리스해야 하거나, 솔루션에 여러 종속성 항목이 있는 경우, 지속적 배포가 유용할 가능성이 큽니다.

지속적 배포와 지속적 제공의 차이점에 대한 자세한 내용은 다음 비디오를 참조하세요.

지속적 제공 툴을 사용하면 애플리케이션을 빌드, 배포, 관리하기 위해 오픈소스 툴을 사용할 수 있습니다. 툴을 통합하면 개발 팀뿐만 아니라 운영 팀을 위해 반복 가능하고 관리 가능한 작업을 만들 수 있습니다.

툴박스에는 현재 사용 중인 클라우드 서비스, 오픈소스 툴, 타사 툴이 포함될 수 있지만, 다음 사항이 포함된 지속적 제공 툴도 고려하는 것이 좋습니다.

• 빌드 및 배포 자동화를 위한 반복 가능한 템플릿. 귀사의 앱 중 하나에 효과가 있다면 다른 앱에도 효과가 있을 것입니다. 모든 팀이 직접 구성하느라 고생하지 않아도 됩니다.
  
  
• 변경 사항을 푸시할 때 자동으로 빌드하고, 클라우드에 배포하고, 빌드와 배포를 툴체인에 통합하고, 툴체인 전반에서 배포를 관리할 수 있도록 지원하는 파이프라인.
  
  
• 팀의 협업, 계획, 소스 코드 관리, 테스트를 위한 툴.
  
  
• 팀이 빠른 진전을 보이는 부분과 난관에 봉착한 부분을 노출시켜 '더 지속적'이 될 수 있도록 길잡이를 제공하는 장치(instrumentation).

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

애자일 지속적 제공

이전에는 소프트웨어를 한 번 릴리스하고 그 다음에는 업데이트를 수행했습니다. 소프트웨어가 고객의 요구 사항을 충족하는지 확인하기 위해 처음과 마지막에만 고객과 상담을 했습니다.

애자일(Agile)은 지속적 제공 일정에 따라 짧은 반복을 통해 소프트웨어를 만드는 방법입니다. 현재의 애자일 지속적 제공 프로세스는 정의된 기능이 제공될 때마다 고객에게 코드를 릴리스할 수 있음을 의미합니다. 애자일 개발과 지속적 제공은 기능이 프로덕션 단계로 진행할 수 있게 되자마자 고객에게 해당 기능을 제공하기 위한 열쇠입니다. 목표는 각 기능이 파이프라인을 떠나면 즉시 릴리스할 수 있도록 하는 것입니다.

애자일 원칙의 장점에 대해 자세히 알아보세요.

DevOps와 지속적 제공

지난 20년 동안 소프트웨어 개발은 표준 폭포수 개념에서 더 효율적인 애자일 방법론으로 이동하며 상당한 변화를 겪었습니다. 변화에 대응하려면 애자일, DevOps, 지속적 제공에 중점을 두는 접근법으로 이동해야 합니다. 지속적 제공 파이프라인의 구성 요소인 이러한 집중된 프로세스는 더 안정적으로 고품질 소프트웨어를 릴리스하고 업데이트하도록 지원합니다.

애자일 개발을 통해 빠른 속도로 소규모 소프트웨어 릴리스를 만들면서 여러분의 관심은 소프트웨어 개발의 개별 단계에 집중될 것입니다. 이와 동시에, DevOps를 통해 개발과 운영이 긴밀하게 하나의 팀으로 합쳐지면서 여러분은 "큰 그림"과 문화적 변화에 관심을 집중할 것입니다. 이러한 하나의 팀은 코딩부터 테스트 그리고 개발과 지원까지 소프트웨어 개발 라이프사이클 전체를 담당합니다.

DevOps 프로세스를 자세히 살펴보려면 아래 비디오를 확인하세요.