지속적 배포란 무엇입니까?

지속적 배포(CD)는 자동화된 테스트 기능을 사용하여 코드베이스에 대한 모든 변경 사항이 정확하고 프로덕션 환경에 자동으로 배포할 준비가 되었는지 확인하는 소프트웨어 릴리스 프로세스입니다. 이 소프트웨어 릴리스 주기는 최근 몇 년 동안 진보되어 왔고 발전해 왔습니다.

소프트웨어 엔지니어링 접근 방식인 CD는 자동화된 배포를 통해 소프트웨어 기능을 정기적으로 제공합니다.

CD는 소프트웨어 릴리스 프로세스로서 자동화된 테스트 기능을 통과하는 경우 새 코드 조각을 자동으로 테스트, 확인하고 프로덕션 환경으로 푸시합니다.

지속적 개발은 지속적 통합의 확장입니다. 지속적 통합을 통해 버그를 찾고 수정할 수 있으며 지속적 배포를 통해 이러한 코드 변경 사항을 자동으로 푸시하여 고객이 항상 최신 소프트웨어를 사용할 수 있도록 합니다. 또한 지속적 배포를 통해 고객에게 빠르고 안정적으로 업데이트를 릴리스할 수 있습니다. 기존 배포와 달리 지속적 배포는 수동 개입 없이 이루어져야 합니다. 지속적 배포의 주요 목표는 소프트웨어 변경의 리드 타임을 줄이고 최종 사용자의 가용성을 높이는 것입니다.

많은 성공을 거둔 소프트웨어 회사가 지속적 배포를 구현한 데는 그럴만한 이유가 있습니다. 소프트웨어 개발자가 기존 소프트웨어에 새로운 코드 줄을 추가하면 변경 사항은 기능과 견고성을 확인하기 위해 자동화된 테스트 세트를 거칩니다. 코드가 자동화된 테스트를 통과하면 최종 사용자가 자동으로 사용할 수 있습니다.

그런 다음 지속적 배포 인프라는 소프트웨어의 동작을 계속 모니터링합니다. 잘못된 동작을 발견한 경우 자동 메커니즘에서 변경 사항을 되돌리고 소프트웨어를 원래 상태로 복원합니다. 이 모든 것은 자동화된 시스템을 통해 진행됩니다. 자동화된 테스트, 배포, 모니터링 및 롤백 프로세스는 모두 지속적 배포 파이프라인의 일부입니다.

기술 회사가 지속적 배포를 채택하는 이유는 무엇입니까?

지속적 배포를 통해 새로운 기능이나 버그 수정 결과가 최종 사용자에게 빠르게 보낼 수 있습니다. 지속적 배포를 위해 구성된 강력한 인프라는 테스트 및 배포 중에 발생할 수 있는 수동 오류를 제거합니다. 또한 소프트웨어의 품질을 향상시키고 기업이 소프트웨어 생산을 확장할 수 있도록 합니다. 지속적 배포는 초기 비용을 제외하고는 비용이 많이 드는 수동 테스트가 필요 없고 지연으로 인한 손실이 없기 때문에 장기적 관점에서 비용을 절약할 수 있습니다.

지속적 배포의 주요 단계는 무엇입니까?

일반적으로 지속적 통합이 지속적 배포보다 우선합니다. 개발자는 코드 조각을 완료하고 단위 테스트를 수행한 다음 이를 지속적 통합 파이프라인에 푸시합니다. 코드와 종속 패키지가 빌드(컴파일)되고 이 새로운 코드 조각이 기존 소프트웨어 시스템과 통합됩니다. 지속적 배포 파이프라인은 이 시점에서 시작됩니다.

1단계: 테스트 및 검증

자동화된 새 코드 테스트는 지속적 배포의 중요한 단계입니다. 자동화된 테스트에는 실시간 사용 사례와 매우 유사한 테스트 시나리오 세트가 포함됩니다. 테스트 집합은 새 코드를 실행하고 이 모든 사용 사례를 통해 전달합니다. 강력하고 자동화된 검증 시스템은 새 코드의 기능을 테스트할 뿐만 아니라 성능, 보안 및 사용성과 같은 비기능 요구사항도 테스트합니다.

자동화된 테스트는 새 코드가 예상대로 작동하는지 확인하고 회귀 문제로 알려진 새로운 문제를 소프트웨어에 발생하지 않게 합니다. 새 코드가 모든 자동화 테스트를 통과하면 최종 사용자가 자동으로 사용할 수 있게 됩니다. 그러나 지속적 배포는 이것이 끝이 아닙니다.

2단계: 상시 모니터링

지속적 배포에는 프로덕션 환경에서 새 코드의 동작과 성능을 지속적으로 모니터링하는 시스템이 있습니다. 이 시스템은 새로운 코드 조각뿐만 아니라 전체 소프트웨어 시스템을 실시간으로 모니터링합니다. 강력한 지속적 배포 인프라는 새 코드가 프로덕션 환경의 소프트웨어에서 문제를 일으키는 경우 경보를 발생합니다. 여기에는 테스트 프레임워크를 트리거하거나 코드 소유자를 호출하는 작업이 포함될 수 있습니다. 이 모니터링 및 경고는 신속하고 실시간으로 이루어지므로 필요한 롤백을 신속하게 수행할 수 있습니다.

3단계: 변경 사항 롤백

강력한 지속적 배포 파이프라인은 프로덕션 문제에 신속하고 효율적이며 지속 가능하게 대응하고 복구할 수 있어야 합니다. 이런 기능은 종종 변경 사항 롤백으로 알려진 새 코드 변경 사항의 자동 철회를 통해 수행됩니다. 많은 경우 최종 사용자는 소프트웨어를 적극적으로 사용하기 때문에 안정적인 버전의 소프트웨어로 롤백하는 기능이 중요합니다. 이 롤백 프로세스와 관련하여 "MTTR(평균 복구 시간)"은 지속적 배포 시스템의 성숙도를 측정하는 중요한 지표입니다. 이 복구 시간은 장애를 감지한 후 소프트웨어를 작동 상태로 복구하는 데 걸리는 시간입니다. MTTR이 높을수록 비즈니스가 손실을 입을 가능성이 높아집니다.

지속적 배포의 모범 사례

테스트 주도 개발

지속적 배포에서는 개발이 소규모로 이루어집니다. 즉, 개발자는 기능의 작은 부분을 작업한 다음 배포합니다. 새로운 기능/버그 수정이 작을 때는 테스트 중심의 개발을 쉽게 수행할 수 있습니다. 코드를 작성하기 전에 다양한 시나리오에서 예상되는 소프트웨어 동작을 설명하는 문서인 동작 사양이 있어야 합니다. 이 사양을 바탕으로 개발자는 단위 테스트 계획을 수립하여 단위 테스트를 더욱 엄격하게 하고 프로덕션 문제를 줄일 수 있습니다.

수동 배포 없음

지속적 배포 시스템이 성공하려면 개발자가 수동으로 코드를 빌드, 통합 또는 배포하는 것을 삼가야 합니다. 변경 사항이 사소해 보이더라도 수동 배포 및 코드 실시간 편집을 통해 지속적 배포 파이프라인에서 불일치를 생성할 수 있습니다.

강력한 자동 테스트 프레임워크

지속적 배포의 핵심 구성 요소 중 하나는 자동화된 테스트입니다. 테스트 프레임워크는 가능한 모든 테스트 시나리오를 다루어야 합니다. 새로운 테스트 시나리오를 포함할 수 있을 만큼 충분히 유연해야 합니다. 자동화된 테스트는 일관성이 있어야 하며 모든 테스트 데이터와 결과는 버전 관리 시스템으로 확인되어야 합니다. 자동화 프레임워크는 처음부터 끝까지 수동 개입 없이 실행되어야 합니다.

지속적 배포의 이점

제품 출시 기간(Time-to-Market) 단축

지속적 배포의 가장 중요한 이점 중 하나는 새로운 기능과 수정 사항을 시장 및 고객에게 빠르게 제공할 수 있다는 것입니다. 점점 더 경쟁이 치열해지는 환경에서 시장 출시 시간은 성공을 위한 중요한 지표입니다. 기존의 수동 배포에서는 코드 검사, 승인 및 최종적으로 사용자를 위한 소프트웨어 출시에 상당한 지연이 있었습니다.

고객 만족도 향상

지속적 배포를 통해 소프트웨어 회사는 고객 피드백에 신속하게 대응할 수 있습니다. 그 피드백은 버그 보고서나 새로운 기능에 대한 요청일 수 있습니다. 어떤 경우이든 회사가 새로운 기능을 개발하거나 버그 수정을 제공하는 즉시(일반적으로 지속적 통합 사용) 지속적 배포 프로세스를 통해 고객에게 빠르게 도달하여 고객 만족도를 높일 수 있습니다.

큰 실패 없음

지속적 배포에서 개발자는 새 코드를 점진적으로 추가합니다. 새 코드는 청크 형태로 발생합니다. 개발자는 커밋하기 전에 이러한 변경 사항을 검사하고 결과를 문서화합니다. 또한 이러한 새로운 변경 사항을 지속적으로 모니터링하는 시스템이 있습니다. 문제가 보고되면 변경 사항이 즉시 되돌려집니다. 중요한 기능이 대규모 코드 변경으로 릴리스되는 기존 배포 프로세스에서는 문제의 원인을 정확히 찾아내기가 어렵습니다. 그러나 지속적 배포를 통해 회사 문제는 신속하게 처리되고 큰 실패는 덜 일반적입니다.

인력의 효율성 증대

지속적 배포는 소프트웨어 개발에서 대부분의 일상적인 작업을 자동화합니다. 개발자는 코드를 통합, 배포 또는 검사하는 방식에 대해 걱정할 필요가 없습니다. 엔지니어는 순전히 작업 품질을 개선하는 데만 집중할 수 있습니다. 또한 새로운 기능을 출시하는 데 걸리는 시간을 줄이는 데 도움이 됩니다. 이제 개발자는 코드 조각을 빠르게 완료하고 배포할 수 있으므로 큰 변경 사항에 대해기다릴 필요가 없습니다.

지속적 배포 대 지속적 개발

지속적 배포에서는 코드 체크인에서 배포, 프로덕션 환경에 이르기까지 모든 단계가 자동화됩니다. 지속적 개발에서 프로덕션 환경에 배포하는 마지막 단계는 수동입니다. 지속적 개발에서 생산에 대한 최종 승인까지의 모든 단계는 자동화됩니다. 단, 새로운 코드가 프로덕션 환경에 들어가기 위해서는 수동 인증/게이트 패스가 필요합니다. 간단히 말해서 지속적 배포는 자동화 측면에서 고급 단계입니다.

지속적 배포 구현의 과제

강력한 지속적 통합 프레임워크

지속적 배포가 작동하려면 견고한 지속적 통합 프레임워크가 있어야 합니다. 여기에는 코드의 지속적 체크인, 자동화된 빌드 및 검사(수동 또는 자동)를 위한 프로세스 및 워크플로가 포함됩니다. 이 프로세스는 원활하고 안전해야 합니다. 이러한 프레임워크를 설정하는 것은 많은 회사에서 어려운 일입니다. 성공적인 지속적 통합에는 개발자, 테스터 및 빌드 엔지니어의 지원이 필요합니다.

지속적 통합을 위해 강력한 시스템을 설정하는 데 시간을 투자하십시오. 하룻밤 사이에 급격한 변화를 일으키지 마십시오. 지속적 통합 프로세스는 한 번에 한 단계씩 구현되어 모든 직원이 같은 페이지에 있는지 확인해야 합니다. 또한 지속적 통합을 모범적으로 준수하는 팀에 인센티브를 제공합니다.

인위적 및 조직적 도전 과제

지속적 배포 제안은 직원과 고객의 마찰에 직면할 수 있습니다. 지속적 배포는 개발 및 테스트 프로세스에서 많은 변경이 필요합니다. 직원들이 지속적 배포 파이프라인에 대한 자신감을 키우는 데는 시간이 걸립니다. 고객의 경우도 마찬가지입니다. 고객은 지속적 배포가 일부 기능을 방해할 수 있다는 두려움 때문에 더 적은 수의 잘 테스트된 릴리스를 고집할 수 있습니다. 또한 팀마다 구현의 성숙도가 다를 수 있습니다. 일부 팀은 아주 열심히 지속적 배포 패러다임을 따르지만 다른 팀은 그렇지 않을 수 있습니다.

각 이해 관계자에 대해 현재 개발 및 배포 프로세스의 문제점을 찾으십시오. 그런 다음 지속적 배포가 이러한 고충을 어떻게 완화할 수 있는지 설명하십시오.

도구 및 리소스의 가용성 및 비용

지속적 배포를 원활하게 실행하려면 많은 도구와 소프트웨어가 필요합니다. 이러한 도구를 구입하고 설치하는 데 비용이 많이 들 수 있습니다. 시장에는 지속적 배포를 위한 수많은 도구가 있습니다. 무엇이 작동하고 무엇이 작동하지 않는지 알아내는 것은 도전입니다. 일부 도구는 조직의 기존 시스템과 호환되지 않을 수 있습니다. 또한 지속적 배포를 구현하려면 서버 및 컴퓨팅 성능과 같은 많은 리소스가 필요합니다. 이러한 리소스를 획득하고 팀 간에 공유하는 것은 또 다른 문제가 될 수 있습니다.

조직 전체에서 소프트웨어와 도구를 쉽게 사용할 수 있도록 합니다. 교육 세션을 실시하고 어떤 도구가 어디에 적합한지 시각적으로 표현하여 직원을 돕습니다. 사용하기 쉽고 수동 구성을 덜 사용하는 도구를 선택하십시오. 지속적 배포 리소스를 공유하기 위한 규칙을 만듭니다.