지속적 통합 및 지속적 전달의 테스트 단계 - AWS에서 지속적인 통합 및 지속적인 전송 적용

지속적 통합 및 지속적 전달의 테스트 단계

세 개의 CI/CD 팀은 CI/CD 파이프라인의 여러 단계에서 소프트웨어 개발 수명 주기에 테스트를 통합해야 합니다. 전반적으로 테스트는 최대한 빨리 시작해야 합니다. 다음 테스트 피라미드는 Mike Cohn이 Agile로 거둔 성과에서 제공하는 개념입니다. 실행 비용 및 속도와 관련된 다양한 소프트웨어 테스트가 표시됩니다.

CI/CD 테스트 피라미드

단위 테스트는 피라미드 맨 아래에 있습니다. 실행 속도가 가장 빠르고 비용도 가장 저렴합니다. 따라서 단위 테스트가 테스트 전략의 대부분을 차지해야 합니다. 경험상 약 70%를 차지하는 것이 좋습니다. 이 단계에서 잡은 버그는 빠르고 저렴하게 수정할 수 있기 때문에 단위 테스트의 코드 적용 범위는 거의 완전해야 합니다.

서비스, 구성 요소 및 통합 테스트는 피라미드의 단위 테스트 위에 있습니다. 이러한 테스트에는 상세한 환경이 필요하므로 인프라 요구 사항에 더 많은 비용이 들고 실행 속도가 느려집니다. 다음 단계는 성능 및 규정 준수 테스트입니다. 이 테스트에는 프로덕션 품질 환경이 필요하며 아직 더 비쌉니다. UI 및 사용자 승인 테스트는 피라미드의 최상위에 있으며 프로덕션 품질 환경도 필요합니다.

이 모든 테스트는 고품질 소프트웨어를 보장하기 위한 전체 전략의 일부입니다. 그러나 개발 속도를 위해서는 피라미드 아래쪽의 테스트 횟수와 적용 범위에 중점을 둡니다.

다음 단원에서는 CI/CD 단계에 대해 설명합니다.

소스 설정

프로젝트를 시작할 때는 원시 코드와 구성 및 스키마 변경 사항을 저장할 수 있는 소스를 설정해야 합니다. 소스 단계에서 GitHub 또는 AWS CodeCommit에서 호스팅되는 소스 코드 리포지토리와 같은 소스 코드를 선택합니다.

빌드 설정 및 실행

빌드 자동화는 CI 프로세스에 필수입니다. 빌드 자동화를 설정할 때 첫 번째 작업은 올바른 빌드 도구를 선택하는 것입니다. 다음과 같은 여러 빌드 도구가 있습니다.

  • Java용 Ant, Maven 및 Gradle

  • C/C++용 Make

  • JavaScript용 Grunt

  • Ruby용 Rake

사용자에게 가장 적합한 빌드 도구는 프로젝트의 프로그래밍 언어와 팀의 기술 집합에 따라 다릅니다. 빌드 도구를 선택한 후에는 빌드 단계와 함께 빌드 스크립트에서 모든 종속성을 명확하게 정의해야 합니다. 또한 최종 빌드 아티팩트의 버전을 관리하는 것이 가장 좋으며, 이렇게 하면 배포가 더 쉬워지고 문제를 추적할 수 있습니다.

빌드

빌드 단계에서 빌드 도구는 소스 코드 리포지토리에 대한 변경 사항을 입력으로 받아 소프트웨어를 빌드하고 다음 유형의 테스트를 실행합니다.

단위 테스트 – 코드의 특정 섹션을 테스트하여 코드가 예상대로 작동하는지 확인합니다. 단위 테스트는 개발 단계에서 소프트웨어 개발자가 수행합니다. 이 단계에서는 정적 코드 분석, 데이터 흐름 분석, 코드 적용 범위 및 기타 소프트웨어 검증 프로세스를 적용할 수 있습니다.

정적 코드 분석 – 이 테스트는 빌드 및 단위 테스트 후 애플리케이션을 실제로 실행하지 않고 수행됩니다. 이 분석은 코딩 오류와 보안 허점을 찾는 데 도움이 될 수 있으며 코딩 지침을 준수하는지 확인할 수 있습니다.

스테이징

스테이징 단계에서는 최종 프로덕션 환경을 반영하는 전체 환경이 생성됩니다. 다음 테스트가 수행됩니다.

통합 테스트 – 소프트웨어 설계와 비교하여 구성 요소 간의 인터페이스를 검증합니다. 통합 테스트는 반복적인 프로세스이며 강력한 인터페이스 및 시스템 무결성을 쉽게 구축할 수 있습니다.

구성 요소 테스트 – 다양한 구성 요소와 결과 간에 전달되는 메시지를 테스트합니다. 이 테스트의 주요 목표는 구성 요소 테스트에서 멱등성이 될 수 있습니다. 테스트에는 매우 큰 데이터 볼륨 또는 에지 상황 및 비정상적인 입력이 포함될 수 있습니다.

시스템 테스트 – 시스템을 종단 간 테스트하고 소프트웨어가 비즈니스 요구 사항을 충족하는지 확인합니다. 여기에는 UI(사용자 인터페이스), API, 백엔드 로직 및 최종 상태의 테스트가 포함될 수 있습니다.

성능 테스트 – 특정 워크로드에서 수행되는 시스템의 응답성 및 안정성을 결정합니다. 성능 테스트는 확장성, 안정성 및 리소스 사용량과 같은 시스템의 다른 품질 속성을 조사, 측정, 검증 또는 확인하는 데에도 사용됩니다. 성능 테스트 유형에는 부하 테스트, 스트레스 테스트 및 스파이크 테스트가 포함될 수 있습니다. 성능 테스트는 사전 정의된 기준에 대한 벤치마킹에 사용됩니다.

규정 준수 테스트 – 코드 변경이 비작동 사양 및/또는 규정의 요구 사항을 준수하는지 확인합니다. 정의된 표준을 구현하고 충족하는지 여부를 결정합니다.

사용자 승인 테스트 – 종단 간 비즈니스 흐름을 검사합니다. 이 테스트는 스테이징 환경에서 최종 사용자가 실행하며 시스템이 요구 사항 사양의 요구 사항을 충족하는지 확인합니다. 일반적으로 고객은 이 단계에서 알파 및 베타 테스트 방법을 사용합니다.

프로덕션

마지막으로 이전 테스트를 통과한 후 프로덕션 환경에서 스테이징 단계가 반복됩니다. 이 단계에서는 전체 프로덕션 환경에 코드를 배포하기전에 서버의 작은 하위 집합이나 한 서버 또는 AWS 리전에만 새 코드를 배포하여 최종 카나리 테스트를 완료할 수 있습니다. 프로덕션에 안전하게 배포하는 방법에 대한 자세한 내용은 배포 방법 단원에서 다룹니다.

다음 단원에서는 이러한 단계와 테스트를 통합하기 위한 파이프라인 구축에 대해 설명합니다.