Continuous Delivery는 실제로 어떻게 작동합니까?

Continuous Delivery는 잘 들리지만, 수년간의 소프트웨어 개발 경험에 따르면 실제로는 작동하지 않습니다.

(편집 : 분명히하기 위해 항상 많은 테스트가 자동으로 실행됩니다. 내 질문은 각 체크인마다 자신감을 얻는 방법에 관한 것입니다. CD의 전체 형태라는 것을 알고 있습니다. 대안은 1 년주기가 아닙니다. 매주 반복 (일부 CD가 올바르게 수행되면 CD로 간주 될 수 있음), 2 주 또는 한 달 (각각 끝에있는 구식 QA 포함, 자동 테스트 추가).

• 전체 테스트 범위는 불가능합니다. 모든 작은 일에 많은 시간과 시간이 필요합니다. 이는 귀중하지만 시간을 다른 방식으로 품질에 기여하는 데 소비 할 수 있습니다.
• 일부는 자동 테스트하기가 어렵습니다. 예 : GUI. 심지어 셀레늄조차도 GUI가 기발한 지 알려줍니다. 부피가 큰 비품이 없으면 데이터베이스 액세스를 테스트하기가 어렵고 심지어 데이터 스토리지의 이상한 경우도 다루지 않습니다. 마찬가지로 보안과 다른 많은 것들. 비즈니스 계층 코드 만 효과적으로 단위를 테스트 할 수 있습니다.
• 비즈니스 계층에서도 대부분의 코드에는 테스트 목적으로 인수와 반환 값을 쉽게 분리 할 수있는 간단한 함수가 없습니다. 실제 구현과 일치하지 않는 모의 객체를 빌드하는 데 많은 시간을 소비 할 수 있습니다.
• 통합 / 기능 테스트는 단위 테스트를 보완하지만 일반적으로 각 테스트에서 전체 시스템을 다시 초기화해야하기 때문에 실행하는 데 많은 시간이 걸립니다. (다시 초기화하지 않으면 테스트 환경이 일치하지 않습니다.)
• 리팩토링 또는 기타 변경으로 인해 많은 테스트가 중단됩니다. 당신은 그것들을 고치는 데 많은 시간을 소비합니다. 의미있는 스펙 변경을 검증해야하는 경우 문제가되지 않지만 실제로 중요한 정보를 제공하는 것이 아니라 의미없는 저수준 구현 세부 사항으로 인해 테스트가 중단되는 경우가 많습니다. 종종 조정은 테스트되는 기능을 실제로 확인하는 것이 아니라 테스트 내부를 재 작업하는 데 중점을 둡니다.
• 버그에 대한 현장 보고서는 코드의 정확한 마이크로 버전과 쉽게 일치시킬 수 없습니다.

수년간의 소프트웨어 개발 경험에 따르면 실제로는 작동하지 않습니다.

사용해 보셨습니까? Dave와 저는 ThoughtWorks에서 실제로 경험 한 여러 해 동안의 경험을 바탕으로 책을 썼습니다. 이 책의 어떤 것도 추측이 아닙니다. 우리가 논의하는 모든 것은 대규모 분산 프로젝트에서도 시도되고 테스트되었습니다. 그러나 우리는 당신이 그것을 믿음으로 받아 들일 것을 제안하지 않습니다. 물론 직접 시도해보아야하고, 다른 사람이 당신의 경험을 통해 배울 수 있도록 관련 내용을 포함하여 자신이 찾은 것과 그렇지 않은 것을 적어 두십시오.

Continuous Delivery는 자동 테스트에 중점을 둡니다. 우리는 책의 약 1/3을 그것에 대해 이야기합니다. 대안 인 수동 테스트는 비용이 많이 들고 오류가 발생하기 쉬우 며 실제로 고품질 소프트웨어를 구축 할 수있는 좋은 방법이 아니기 때문에이 작업을 수행합니다. 처음부터 제품 ")

전체 테스트 범위는 불가능합니다. 모든 작은 일에 많은 시간과 시간이 필요합니다. 이는 귀중하지만 시간을 다른 방식으로 품질에 기여하는 데 소비 할 수 있습니다.

물론 전체 테스트 범위는 불가능하지만 대안은 무엇입니까 : 테스트 범위 제로? 절충이 있습니다. 그 중간에 프로젝트에 대한 정답이 있습니다. 일반적으로 자동화 된 테스트를 작성하거나 유지하는 데 약 50 %의 시간이 소요될 것으로 예상됩니다. 포괄적 인 수동 테스트 비용과 사용자에게 제공되는 버그를 수정하는 비용을 고려할 때까지 비용이 많이들 수 있습니다.

일부는 자동 테스트하기가 어렵습니다. 예 : GUI. 심지어 셀레늄조차도 GUI가 기발한 지 알려줍니다.

당연하지. Brian Marick의 테스트 사분면을 확인하십시오. 탐색 테스트 및 유용성 테스트를 수동으로 수행해야합니다. 그러나 이것이 회귀 테스트가 아닌 값 비싸고 소중한 사람을 사용해야하는 것입니다. 핵심은 포괄적 인 자동화 된 테스트 제품군을 통과 한 빌드에 대해 값 비싼 수동 유효성 검사 만 수행 할 수 있도록 배포 파이프 라인을 배치해야한다는 것입니다. 따라서 수동 테스트에 소비하는 비용과 수동 테스트 또는 생산에 소요되는 버그의 수를 줄입니다 ( 수정 비용 이 많이 드는 시간 ). 자동화 된 테스트 는 제품 수명주기보다 훨씬 저렴하지만 물론 시간이 지남에 따라 막대한 비용이 소요됩니다.

부피가 큰 비품이 없으면 데이터베이스 액세스를 테스트하기가 어렵고 심지어 데이터 스토리지의 이상한 경우도 다루지 않습니다. 마찬가지로 보안과 다른 많은 것들. 비즈니스 계층 코드 만 효과적으로 단위를 테스트 할 수 있습니다.

데이터베이스 액세스는 엔드 투 엔드 시나리오 기반 기능 승인 테스트에 의해 내재적으로 테스트됩니다. 보안에는 자동 및 수동 테스트-자동 침투 테스트 및 정적 분석 (예 : 버퍼 오버런 찾기)의 조합이 필요합니다.

비즈니스 계층에서도 대부분의 코드에는 테스트 목적으로 인수와 반환 값을 쉽게 분리 할 수있는 간단한 함수가 없습니다. 실제 구현과 일치하지 않는 모의 객체를 빌드하는 데 많은 시간을 소비 할 수 있습니다.

물론 자동화 된 테스트는 소프트웨어와 테스트를 잘못 구축하면 비용이 많이 듭니다. 시간이 지남에 따라 테스트와 코드를 유지 관리 할 수 ​​있도록 올바르게 수행하는 방법을 이해하려면 "테스트에 따라 성장하는 객체 지향 소프트웨어"책을 확인하는 것이 좋습니다.

통합 / 기능 테스트는 단위 테스트를 보완하지만 일반적으로 각 테스트에서 전체 시스템을 다시 초기화해야하기 때문에 실행하는 데 많은 시간이 걸립니다. (다시 초기화하지 않으면 테스트 환경이 일치하지 않습니다.)

내가 작업했던 제품 중 하나에는 18 시간 동안 실행되는 3,500 개의 엔드-투-엔드 승인 테스트가 있습니다. 우리는 70 상자의 그리드에서 병렬로 실행하고 45m 안에 피드백을 얻습니다. 이상적으로는 실제보다 오래 걸리기 때문에 단위 테스트가 몇 분 후에 실행 된 후 파이프 라인에서 두 번째 단계로 실행되므로 기본 수준이없는 빌드에서 리소스를 낭비하지 않습니다. 자신감.

리팩토링 또는 기타 변경으로 인해 많은 테스트가 중단됩니다. 당신은 그것들을 고치는 데 많은 시간을 소비합니다. 의미있는 스펙 변경을 검증해야하는 경우 문제가되지 않지만 실제로 중요한 정보를 제공하는 것이 아니라 의미없는 저수준 구현 세부 사항으로 인해 테스트가 중단되는 경우가 많습니다. 종종 조정은 테스트되는 기능을 실제로 확인하는 것이 아니라 테스트 내부를 재 작업하는 데 중점을 둡니다.

코드와 테스트가 잘 캡슐화되고 느슨하게 결합 된 경우 리팩토링으로 인해 많은 테스트가 중단되지 않습니다. 우리는 책에서 기능 테스트를 위해 같은 일을하는 방법을 설명합니다. 승인 테스트가 중단되면 하나 이상의 단위 테스트가 누락되었다는 신호이므로 CD의 일부에는 테스트 범위가 더 세분화 된 전달 프로세스에서 버그를 찾아서 찾기 위해 테스트 범위를 지속적으로 개선해야합니다. 버그를 수정하는 것이 더 저렴합니다.

버그에 대한 현장 보고서는 코드의 정확한 마이크로 버전과 쉽게 일치시킬 수 없습니다.

더 자주 (CD 포인트의 일부) 테스트하고 릴리스 하는 경우 버그를 일으킨 변경을 식별하는 것이 비교적 간단합니다. CD의 전체 요점은 피드백주기를 최적화하여 버그를 버전 제어에 체크인 한 후 가능한 빨리 버그를 식별 할 수 있도록하는 것입니다. 실제로 버그가 체크인되기 전에 버그를 식별 할 수 있습니다 (빌드 및 단위 테스트를 실행하는 이유) 체크인 전).

첫째, CD는 하나의 큰 정신적 조정을 취합니다. 때로는 어떤 일을 하든지 문제가 발생한다는 것을 인정해야합니다. 하루가 끝나면 부정적인 것을 증명할 수 없습니다.

이 과정을 마치면 a) 이러한 오류를 매우 신속하게 파악하고 b) 업데이트를 매우 효율적으로 롤백하거나 배포하기위한 도구와 절차가 필요하다는 것을 알게됩니다. 또한 CD 칵테일을 마시고 있다면 롤백하기 쉽고 작고 응용 프로그램 전체의 버그를 유발할 수없는 작고 뾰족한 변경 사항을 많이 제공하고 있습니다. 실제로 CD를 연습하는 사람들조차도보다 전통적인 방식으로 주요 전환을 처리하고 있습니다.

모든 시스템에는 위험이 있으며 모든 위험에는 잠재적 인 비용이 있습니다. 광범위한 테스트 및 QA에서 발견하는 데 몇 개월 또는 몇 년이 걸릴 수있는 작은 위험의 비용이 충분히 높으면 (심장 박동기의 소프트웨어) 광범위한 테스트 기간 없이는 배송 할 수 없습니다 냉동 방출. 실패 비용이 충분히 적은 경우, 제로 테스트 (고양이의 Facebook 페이지)로 계속 배송 할 수 있습니다.

전체 테스트 범위는 불가능합니다. 모든 작은 일에 많은 시간과 시간이 필요합니다. 이는 귀중하지만 시간을 다른 방식으로 품질에 기여하는 데 소비 할 수 있습니다.

100 % 적용 범위가 필요하지 않으며 시스템에 대한 확신이 충분해야합니다. 한 곳으로 변경해도 이전에 입증 된 작업이 중단되지 않습니다.

일부는 자동 테스트하기가 어렵습니다. 예 : GUI. 심지어 셀레늄조차도
GUI가 기발한 지 알려줍니다. 부피가 큰 비품이 없으면 데이터베이스 액세스를 테스트하기가 어렵고 심지어 데이터 스토리지의 이상한 경우도 다루지 않습니다.

그러나 데이터베이스 액세스는 쓰기가 쉽지 않습니다. 데이터를 가져오고 설정하기 만하면 데이터 레이어에 대한 많은 테스트가 필요하지 않습니다. 가장 중요한 것은 실패했을 때 롤백하고 문제를 기록하여 해결할 수 있도록하는 것입니다.

마찬가지로 보안과 다른 많은 것들. 비즈니스 계층 코드 만 효과적으로 단위를 테스트 할 수 있습니다. 비즈니스 계층에서도 대부분의 코드에는 테스트 목적으로 인수와 반환 값을 쉽게 분리 할 수있는 간단한 함수가 없습니다.

그런 다음 많은 함수 / 클래스가 너무 큽니다. 테스트 할 수 있도록 작성해야합니다.

실제 구현과 일치하지 않는 모의 객체를 빌드하는 데 많은 시간을 소비 할 수 있습니다.

그러나 모의 객체의 I / O는 예상 한 것과 일치해야합니다. 그 안에 무슨 일이 중요하지 않습니다.

통합 / 기능 테스트는 단위 테스트를 보완하지만 일반적으로 각 테스트에서 전체 시스템을 다시 초기화해야하기 때문에 실행하는 데 많은 시간이 걸립니다. (다시 초기화하지 않으면 테스트 환경이 일치하지 않습니다.)

이것들은 항상 실행되어서는 안됩니다. 필요에 따라

리팩토링 또는 기타 변경으로 인해 많은 테스트가 중단됩니다. 당신은 그것들을 고치는 데 많은 시간을 소비합니다. 의미있는 스펙 변경을 검증해야하는 경우 문제가되지 않지만 실제로 중요한 정보를 제공하는 것이 아니라 의미없는 저수준 구현 세부 사항으로 인해 테스트가 중단되는 경우가 많습니다. 종종 조정은 테스트되는 기능을 실제로 확인하는 것이 아니라 테스트 내부를 재 작업하는 데 중점을 둡니다.

그런 다음 코드가 너무 밀접하게 결합되어 테스트가 제대로 작성되지 않았습니다.

버그에 대한 현장 보고서는 코드의 정확한 마이크로 버전과 쉽게 일치시킬 수 없습니다.

당신이 여기서 무엇을 얻고 있는지 잘 모르시겠습니까? 버그가 있으면 테스트를 작성하여 존재 여부를 표시 한 다음 수정하십시오.

우리에게는 잘 작동하지만 고객은 대부분 내부적입니다. 낮 동안 수행 된 여러 빌드, 깨진 빌드는 허용되지 않으며 웹 시작 메커니즘을 사용하므로 사용자는 모든 버전의 최신 버전을 얻을 수 있습니다. 한 가지는 CD가 많은 문제를 해결한다는 것입니다. 예, 항상 호환성 문제가 있지만 매번 작은 변경 사항 만 배포하기 때문에 문제를 쉽게 처리 할 수 ​​있습니다. CD의 스트레스 수준은 우리가 큰 업데이트를 할 때보 다 훨씬 낮으며 파손의 경우 검토해야 할 코드가 너무 많기 때문에 모든 것이 옳았기를 바랍니다.

솔직히 말하면, 모든 소프트웨어는 지속적으로 제공됩니다! 가장 중요한 것은 문 밖으로 나가는 것입니다! 사용자가이를 사용하게하고 그 후에 기능 요청 및 버그 스 쿼싱의 우선 순위를 정하십시오.

"실제 예술가 배"
-스티브 잡스.