결제 서비스 변경은 수천 개의 단위 테스트를 통과할 수 있지만 빌링 API이 서비스가 기대하는 것과 다르게 아이디엠토네시 키를 해석하는 경우 프로덕션에서 깨질 수 있습니다. 실패는 밤에 통합 작업이 인터페이스를 만날 때까지 눈에 띄지 않을 수 있으며, 커밋은 PIPELINE의 빠른 부분을 통과한 후에 이미 이동했습니다.
그것이 CI/CD PIPELINE의 운영 문제 CI/CD 통합 테스트. 단위 테스트는孤立된 논리가 올바르게 작동하는지 증명합니다. 통합 테스트는 구성 요소, 서비스, 스키마, 큐, 외부 의존성 등이 여전히 일치하는지 증명합니다. 현대적인 배포 PIPELINE에서 이러한 증거는 문제 해결 결정에 영향을 주어야 하며, 개발자가 무시하는 느린 검사로 변하지 않아야 합니다.
CI/CD는 소프트웨어 배포 모델로 주류화되었습니다. 2024년 mabl에서 발행한 DevOps 테스트 보고서 세계적인 조직의 거의 90%가 DevOps 전환을 우선순위로 두고 있으며, 테스터가 CI/CD 프로세스를 정의하고 유지하는 데 참여하는 사람의 비율은 약 이고, 조직 중 50% 은 CI/CD를 배포하지 않는다고 보고했습니다. 실질적인 결과는 명확합니다: 통합 검증은 배포 규모에서 작동해야 합니다. 10% 목차
통합 테스트가 CI/CD의 제어점이 되는 이유
- 제어점을 의도적으로 구축하십시오
- 통합 테스트는 단위 테스트와 종단 간 테스트 사이에 위치합니다.
- 신뢰할 수 있는 테스트를 위해 환경과 데이터를 관리하는 방법
- GitHub 액션의 PIPELINE 예시, GitLab CI, Jenkins
- 불안정한 통합 테스트에 대한 신뢰도 전략
- CI/CD 통합 테스트
- 장기 신뢰를 위한 수용성 체크리스트
CI/CD 통합 테스트의 제어점
통합 테스트는 릴리스 위험을 구체화하는 지점입니다. 단위 테스트는 결제 처리기에서 idempotency key를 올바르게 형식화하는지 확인할 수 있지만, 통합 테스트만이 처리기, HTTP 클라이언트, 결제 API, 영구 저장소 layer, 재시도 동작이 함께 작동할 때 일치하는지 증명할 수 있습니다.
통합 테스트는 CI/CD pipeline 내에서 중요한 품질 제어 지점으로 작용합니다. 커밋은 단위 테스트가 녹색일 뿐만 아니라, 변경된 인터페이스가 실제 환경과 유사한 환경에서 작동하는지 증명하는 신뢰할 수 있는 증거를 생산할 때만 배포될 수 있습니다.
CI/CD 통합 테스트의 차이점은 자동 검증이 없는 빈번한 통합만 결함을 더 빠르게 이동시키기 때문입니다. CI/CD 개선 방법에 대한 체계적인 검토에서 반복되는 우선순위가 포함되어 있습니다. 이 우선순위에는 빌드 및 테스트 시간을 줄이기, 결과에 대한 시각성을 개선하기, 지속적인 테스트를 지원하기, 결함을 감지하기, 배포 신뢰성을 개선하기 등이 포함됩니다. 동일한 연구 기록에서 정의한 지속적인 통합은 빈번한 code 통합을 자동 빌드가 포함된 테스트로 검증하는 것입니다. 결함을 빠르게 감지할 수 있습니다.
제어점을 의도적으로 구축하십시오.
CI/CD 통합 테스트를 분류하기 시작하십시오.
- 장애 테스트 중요한 계약을 보호하고 병합 또는 승인 전에 동기적으로 실행하십시오.
- 격리된 테스트 불안정성을 조사하는 동안 팀이 배달을 중단하지 않도록 계속해서 증거를 생산하되 가시성을 유지하십시오.
- 비동기 테스트 더 광범위한 워크플로우, 전체 스테이징 구성, 또는 비용이 많이 드는 인프라를 실행하기 위해 커밋이 빠른 게이트를 통과한 후.
이것은 모든 테스트가 'CI'에 있어야 하는지 여부를 논쟁하는 것보다 더 유용합니다. 올바른 질문은 특정 승인 결정에 영향을 미치는지 여부를 결정하는 테스트가 신뢰할 수 있고 충분히 가치 있는지 여부입니다.
실용적인 규칙: 안정적인 통합 증거에 게이트를 걸지 마십시오. 통합 스위트의 존재에 게이트를 걸지 마십시오.
구현의 나머지 부분은 그 규칙에서 따릅니다. 프로덕션과 같은 의존성을 사용하여 인터페이스가 실패할 수 있는 경우, 독립적인 체크를 병렬화하고, 가짜 실패를 측정하고, 격리 및 승진에 대한 명시적인 조건을 정의하세요. 이 작업을 더 광범위한 배달 관행과 연결하고 싶은 팀도 이 작업을 검토할 수 있습니다. 연속적 통합의 이점을 검토하세요..
단위 테스트와 종단 간 테스트 사이에 통합 테스트가 위치하는 곳입니다.
테스트 피라미드는 비용 모델이며 rig한 법은 아닙니다. 단위 테스트는 함수, 클래스 또는 모듈을 분리하여 빠르기 때문에 즉시 feedback을 제공합니다. mocks는 시스템의 구멍에서 발생하는 정확히 실패를 숨길 수 있습니다. 예를 들어, 직렬화 차이, 데이터베이스 제약 조건, 인증 구성 또는 큐 동작과 같은.
종단 간 테스트는 사용자 경로를 전체 스택에서 실행하여 고위험 워크플로에 대한 가치가 있습니다. 또한 브라우저, 네트워크, 서비스 및 인프라 경계를 넘어 가며, 진단 및 안정성이 더 어려워집니다. 모든 병합이 종단 간의 모든 부품을 기다리면 개발자는 느린 신호를 받게 되며, 종종 API-레벨 통합 테스트보다 더 집중된 정보를 제공하지 않습니다.
통합 테스트는 중간 지대에 위치합니다. 실제 또는 근사한 의존성을 사용하여 서비스 간의 동작을 검증할 수 있으며, 완전한 UI 오케스트레이션을 요구하지 않습니다. layer는 HTTP 및 gRPC 호출, 큐 게시, 데이터베이스 마이그레이션, 캐시 상호 작용 및 스키마 호환성을 커버할 수 있습니다.
세 가지 유용한 통합 패턴
Testcontainers를 사용한 인스턴스 내 컴포넌트 테스트 애플리케이션 컴포넌트와 종속성인 PostgreSQL, Redis, Kafka와 같은 것을 함께 시작합니다. 이 패턴은 영속성, 직렬화, 거래, 브로커 의미론과 같은 결함 위험이 있는 경우에 설정 비용이 가치가 있습니다. 테스트에 실제 종속성을 제공하면서 테스트 경계를 좁게 유지합니다.
Pact 또는 스키마 레지스트리를 사용한 크로스 서비스 계약 테스트 소비자와 제공자 간의 계약에 초점을 맞추어야 합니다. 서비스가独立적으로 릴리즈되고 계약 이탈에 대한 빠른 feedback이 필요할 때 팀이 강력한 선택입니다. 계약 테스트는 행동적 통합 테스트를 대체하지 않아야 하지만 공유 환경에 도달하기 전에 호환되지 않는 인터페이스를 방지할 수 있습니다.
API-레벨 테스트 여러 배포된 서비스를 실제 네트워크 경로를 통해 호출합니다. 라우팅, 인증, 서비스 발견, 배포 구성, 또는 인프라 정책이 중요한 워크플로우에서 이 패턴을 사용합니다. 그러나 전체 스테이징 스택은 더 비용이 들고 실패할 때 분리하기 어려우므로 비즈니스 крит적 경로만 유지해야 합니다.
| 패턴 | 런타임 | 환경 일치도 | 어떤 경우에 가장 좋음 |
|---|---|---|---|
| Testcontainers를 사용한 인스턴스 내 컴포넌트 테스트 | 빠른~중간 | __CAPGO_KEEP_0__ | 데이터베이스, 캐시, 브로커 및 애플리케이션 컴포넌트 동작 |
| Pact 또는 스키마 레지스트리와의 소비자-제공자 계약 테스트 | 빠른 | 고급 인터페이스 신뢰도 | API와 Independently Released 서비스 간의 이벤트 호환성 |
| API가 구성된 스테이징 스택에 테스트 | 중간~느린 | 고급 시스템 신뢰도 | 네트워크 경로, 인증, 라우팅 및 중요 다중 서비스 워크플로우 |
동기화 병합 스위트를 의도적으로 좁게 유지하세요. 실용적인 목표는 통합 경로 10분 이내의 merge commit, 그 다음에 비용이 많이 드는 시나리오를 비동기적 실행으로 옮깁니다. 자동화된 테스트가 무엇을 포함하는지 살펴보세요., 그러나 결정적인 원칙은 간단합니다: 현실성을 보장하는 데 드는 비용을 결정에 영향을 미치는 경우에만 지불하세요.
신뢰할 수 있는 테스트를 위해 환경과 데이터를 관리하는 방법
잘못된 환경에 테스트를 실행하는 테스트는 오류에 대한 자신감을 부여할 수 있습니다. 불안정한 공유 환경에 테스트를 실행하는 테스트는 오류를 발생시킬 수 있습니다. 신뢰할 수 있는 CI/CD 통합 테스트 신뢰할 수 있는 CI/CD 통합 테스트를 위해 환경 전략이 의존성 경계를 명확하게 하고 데이터 상태를 재현할 수 있어야 합니다.
먼저 신뢰할 수 있는 의존성을 시작하세요. Testcontainers는 각 작업에 대해 임의로 PostgreSQL, Redis, Kafka 인스턴스를 제공할 수 있습니다. Docker 자체가 중요한 것이 아니라, 버전, 구성, 시작, 종료를 제어할 수 있다는 것이 중요합니다.
재현 가능한 작업 순서
테스트 code가 설정을 임의로 결정하는 대신 고정된 순서를 사용하세요:
- 실행 중인 종속성을 시작합니다. PostgreSQL 컨테이너를 부팅하고, 실제 헬스 체크 대신에 프로세스가 트래픽을 수용할 준비가 되었는지 가정하지 말고 기다립니다.
- 이주를 적용합니다. 애플리케이션에서 사용하는 동일한 이주 경로를 실행하십시오. 테스트 스키마를 수동으로 관리하는 것이 아니라 프로덕션과 드리프트가 발생하지 않도록 하십시오.
- 결정론적 fixture를 로드합니다. scenario에 필요한 레코드만 시드하고, 각 작업에 고유한 데이터를 제공하여 병렬 실행이 서로의 상태를 변형하지 못하도록 하십시오.
- 계약 확인을 실행합니다. 요청 형식, 응답 동작, 이벤트 스키마, 상태 전환 및 영구성 결과를 확인합니다.
- 모든 것을 해체합니다. 테스트가 실패하더라도 나중에 작업이 부정확한 상태를 상속하지 않도록, 컨테이너와 임시 볼륨을 완전히 삭제하십시오.
90초의 PostgreSQL 부팅이 이주 및 거래 오류를 잡을 수 있는 합리적인 비용일 수 있습니다. 완전한 스테이징 클러스터는 다른 결정입니다. 더 많은 인프라를 소비하고, 더 많은 구성 드리프트를 유발하고, 더 많은 실패 원인이 발생할 수 있는 곳을 증가시킵니다. 가장 좁은 충실한 환경에서 시작하고, 계약 커버리지 또는 프로덕션 사고가 더 작은 경계가 의미 있는 실패 모드를 누락하고 있음을 보여주면, 그 경계를 넓혀보십시오.
의도된 가상화 사용
어떤 제 3 자 시스템은 모든 pipeline에서 안전하게 프로비전 될 수 없습니다. WireMock, Mountebank, Hoverfly는 의존성을 시뮬레이션 할 수 있지만, 시뮬레이션은 유지 관리 된 계약으로 다루어야 하며 편리한 탈출구가 아닙니다. ideal 반응만 반환하는 mock은 인증 만료, 속도 제한, 오류가 있는 페이로드, 타임아웃 처리, 스키마 진화와 같은 것을 드러내지 않습니다.
임시 미리보기 환경은 여러 배포 된 서비스가 함께 작동할 때 위험에 의존할 때 유용합니다. Docker Compose는 compact한 local 및 CI 구성이 가능하며, Kubernetes namespace는 배포 동작 자체가 테스트 될 때 pull-request 환경을 분리할 수 있습니다. 사용하는 방법에 관계없이 의존성 버전을 고정하고 각 실행에 사용된 구성 기록하세요.
비밀은 데이터와 같은 discipline이 필요합니다. 테스트 fixture 외부에서 자격 증명을 저장하고 플랫폼의 보호된 메커니즘을 통해 접근 권한을 rotate하세요. Capgo CI/CD pipeline에서 비밀을 관리하는 방법에 대한 안내서 환경 생명 주기를 팀이 동의하는 데 도움이 되는 짧은 시각적인 walkthrough가 필요합니다:
__CAPGO_KEEP_0__ Actions, GitLab CI, Jenkins에 대한 pipeline 예제
Pipeline Examples for GitHub Actions, GitLab CI, and Jenkins
__CAPGO_KEEP_0__ Actions
GitHub CI/CD pipeline에서 비밀을 관리하는 방법에 대한 안내서
A matrix는 도메인 또는 샤드에 따라 통합 테스트를 분할할 수 있는 경우 잘 작동합니다. 서비스 컨테이너는 의존성을 실행자와 가깝게 유지하면서, JUnit 출력은 pull 요청과 하류 시스템에 안정적인 결과 형식을 제공합니다.
name: integration
on:
pull_request:
jobs:
integration:
strategy:
fail-fast: false
matrix:
suite: [billing, orders, notifications]
runs-on: ubuntu-latest
services:
postgres:
image: postgres:16
env:
POSTGRES_PASSWORD: test
POSTGRES_DB: app_test
options: >-
--health-cmd "pg_isready -U postgres -d app_test"
--health-interval 5s
--health-timeout 5s
--health-retries 12
redis:
image: redis:7
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 22
- run: npm ci
- run: npm run test:integration, --suite=${{ matrix.suite }}
- if: always()
uses: actions/upload-artifact@v4
with:
name: junit-${{ matrix.suite }}
path: test-results/*.xml버전을 고정하는 액션 및 의존성은 환경의漂移을 줄입니다. GitHub Actions는 행렬과 별도의 작업을 통해 병렬성을 주로 노출합니다. 따라서 행렬을 사용하는 경우 각 샤드가 고립된 데이터와 예측 가능한 지속 시간을 가질 때만 사용하십시오.
GitLab CI
GitLab CI는 준비, 테스트 실행 및 보고를 분리할 수 있습니다. 자식 pipe는 큰 저장소가 여러 서비스를 소유하고 다른 통합 환경을 가질 때 유용합니다. Artifacts는 테스트 작업이 실패하더라도 JUnit 결과를 보존합니다.
stages:
- build
- integration
build-image:
stage: build
script:
- docker build --tag "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA" .
- docker push "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA"
integration:
stage: integration
parallel:
matrix:
- SUITE: [billing, orders, notifications]
image: "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA"
services:
- name: postgres:16
alias: postgres
- name: redis:7
alias: redis
script:
- ./scripts/migrate-test-db.sh
- npm run test:integration, --suite="$SUITE" --reporter=junit
artifacts:
when: always
reports:
junit: test-results/*.xml서비스 소유권 또는 배포 토폴로지로 인해 단일 모노리틱 파일을 유지하기 어려운 경우 GitLab 자식 pipe를 사용하십시오. 부모 pipe는 승인 결정에 책임을 지우면, 개별 자식이 통과할 수 있지만 전체 릴리스 신호가 모호해질 수 있습니다.
Jenkins
Jenkins는 팀이 자체 호스팅 에이전트 또는 비정상적인 네트워크 접근이 필요한 경우 유용합니다. 선언적 Jenkinsfile는 Docker 기반 에이전트를 할당하고 스위트를 병렬로 실행할 수 있지만 팀은 플러그인, 컨트롤러, 에이전트 및 이미지 유지 관리에 책임을 지게 됩니다.
pipeline {
agent none
stages {
stage('Build') {
agent { docker 'node:22' }
steps {
sh 'npm ci'
sh 'npm run build'
stash name: 'build', includes: 'dist/**'
}
}
stage('Integration') {
parallel {
stage('Billing') {
agent { docker 'my-org/integration-runner:stable' }
steps {
unstash 'build'
sh './scripts/start-test-dependencies.sh'
sh 'npm run test:integration, --suite=billing'
}
}
stage('Orders') {
agent { docker 'my-org/integration-runner:stable' }
steps {
unstash 'build'
sh './scripts/start-test-dependencies.sh'
sh 'npm run test:integration, --suite=orders'
}
}
}
}
}
post {
always {
junit 'test-results/*.xml'
}
}
}| 기능 | GitHub Actions | GitLab CI | Jenkins |
|---|---|---|---|
| 병렬 실행 | Matrix 작업과 분리된 작업 | parallel Matrix 작업과 |
선언적 parallel 단계와 분산된 agent |
| 환경 제어 | 호스트 또는 자체 호스트된 실행자 | 호스트 또는 자체 호스트된 실행자 | 자체 관리 컨트롤러 및 agent |
| 결과 표시 | 아티팩트 및 체크 어노테이션 | JUnit 리포트 및 아티팩트 | JUnit 퍼블리셔 및 빌드 기록 |
| 버전 재현 가능성 | pinned 액션, 이미지 및 설정 버전 | pinned 이미지 및 실행자 구성 | pinned agent 이미지 및 제어된 플러그인 |
| 최적의 운영 적합성 | GitHub-중심화된 저장소 | GitLab-centered 배포 | 확장된 자체 호스팅 맞춤화를 필요로 하는 팀 |
For teams already using GitHub, automated build and release with GitHub Actions 이러한 팀은 __CAPGO_KEEP_0__-centered 저장소에서
자동화된 빌드 및 릴리즈와 Capgo Actions를 사용할 수 있습니다. 중요한 디자인 선택은 모든 세 가지 실행자에서 동일합니다: 비싼 모든 테스트를 동기화된 병목 현상으로 만들지 마십시오.
재시도는 진단에 유용하지만 blanket 재시도는 불안정한 신뢰 전략입니다. 그들은 실제 결함을 녹색 빌드로 바꾸고 환경 불안정성을 숨기고 실제 PIPELINE보다 건강한 보다 보이게 만들 수 있습니다.
문제의 규모는 공개된 엔지니어링 데이터에서 볼 수 있습니다. Google은 약 16%의 테스트 에 대한 일부 불안정성과 약 1.5%의 모든 테스트 실행 불안정한 결과를 반환하는 경우, 다른 연구에서는 Google 테스트 실패의 약 4.56%가 불안정한 테스트로 인해 발생했습니다. AWS 지속적인 통합 및 배포 테스트 지침에서 요약된 것입니다. Google 데이터는 약 84%의 PASS-TO-FAIL CI 전환 4.6%의 불안정한 테스트 한 연구에 따르면, Panto에서 제공하는 불안정한 테스트 통계 리뷰에 따르면
정책 변경하기 전에 측정하십시오
불안정성 추적하기:
불안정한 실패 ÷ 총 실행 횟수 × 100
7일에서 30일의 기간을 사용하십시오 그리고 suite, 테스트, 실행자 이미지, 의존성, 환경에 따라 계산하십시오. 하나의 실행자에서만 실패하는 테스트는 모든 환경에서 실패하는 테스트와 다른 해결책입니다.이러한 분류를 사용하십시오:
제품 실패:
- 관련 게이트를 차단하고 __CAPGO_KEEP_0__ 또는 계약을 수정하십시오. block the relevant gate and fix the code or contract.
- 환경 오류: 보안, 리소스 제한, 네트워킹, 의존성 설정을 확인하세요.
- 테스트 오류: 주문서 오류, 공유 상태, 타이밍, 정리, 또는 fixture 설계를 수정하세요.
- 분류되지 않은 instablity: 일시적으로 격리하고, 소유주와 만료일을 지정하세요.
일반적인 원인 제거:
공유 mutable 상태는 순서 의존성을 만듭니다. 각 작업에 고유한 스키마, 유일한 식별자, 또는 트랜잭션 롤백 경계를 제공하세요. 비동기 시스템은 조건에 따라 폴링을 사용하세요. 그리고 시간 제한을 설정하세요. 대신에 프로세스 시작 대기 시간을 사용하지 마세요. 만료 로직에 시계를 주입하고, 컨테이너의 건강을 기다리세요.
샤딩은 시간을 절약하지만, 테스트가 나쁘다면 해결되지 않습니다. 샤드별로 독립적으로 실행하고, 모든 샤드의 로그를 보존하고, 실패한 테스트 또는 샤드만 다시 실행하세요. 환경 오류로 인해 하나의 통합 체크만 실패했다면 전체 pipeline을 다시 실행하지 마세요.
테스트는 환경에서 충분한 안정성 정책을 충족해야만 격리에서 풀릴 수 있습니다. 예를 들어, 테스트가 실행될 환경에서 연속적으로 녹색 실행이 이루어졌을 때입니다. 정확한 기준은 팀이 선택하고 기록해야 합니다. 중요한 것은 승격이 관찰된 안정성에 의해 이뤄지며, 격리 레이블을 삭제하는 것이 아니라는 것입니다.
게이트 정책 및 배포 승격 규칙:
품질 게이트는 다음 환경으로 이동할 수 있는 artifact가 충분한 신뢰할 수 있는 증거를 가지고 있는지 여부를 확인해야 합니다. 게이트는 모든 테스트를 모아놓은 곳이 아닌, 신뢰할 수 있는 증거가 충분한 artifact가 있는지 여부를 확인해야 합니다.
자동화 격차는 경고입니다. 2025년 조사에 의하면 Testkube의 CI/CD 테스트 분석 보고서에 따르면 72%의 조직 CI/CD에서 자동화된 QA를 사용하고 있지만 26% 테스트가 실패할 때 배포를 차단하는 품질 게이트를 설정하지 않았다고 합니다.
자동화만으로는 품질을 보장할 수 없습니다.
단계별 게이트를 사용하세요.
| 커밋 시, 빠른 단위 테스트와 변경된 또는 중요 인터페이스를 보호하는 안정적인 통합 부분에 대한 테스트를 차단하세요. | 스테이징 시, 더 광범위한 구성된 환경 체크와 배포 구성 유효성 검사를 추가하세요. | 프로덕션 이전에, 승인된 아티팩트, 성공적인 보호된 환경 유효성 검사, 그리고 위험 모델이 승인 요구를 명시하는 경우에는 명시적인 승인을 요구하세요. | 단계 |
|---|---|---|---|
| 커밋 또는 풀 요청 | 모든 차단 확인이 통과됩니다. | 차단된 서브셋 외부의 테스트만 허용됩니다. | 자동화된 머지 보호 |
| 스테이징 승격 | 모든 중요 통합 확인이 통과됩니다. | 문서화된 소유자와 위험 검토가 있는 경우에만 허용됩니다. | 팀 또는 서비스 소유자 |
| 카나리 또는 제한된 롤아웃 | 승격 확인 및 실시간 헬스 신호가 통과됩니다. | 보호된 경로를 포함하는 보호된 테스트가 없습니다. | 온콜 또는 릴리스 소유자 |
| 운영 환경 승인 | 모든 필수 게이트가 감사 증거를 통과합니다. | 차단 경로 격리 없음 | 정책이 요구하는 경우 명시적 승인 |
‘통과율’을 ‘raw 퍼센티지 목표’와 혼동하지 마세요. 스위트가 높은 통과율을 나타낼 수 있지만 반복적으로 실패하는 정확한 결제 또는 인증 경로가 중요합니다. 중요 경로 커버리지에 따라 동작을 정의하고, 그 체크를 결정적으로 통과하도록 요구하세요.
비활성화 경로를 표시하세요
Branch 보호를 구성하여 실패하는 차단 체크가 병합을 방지하도록 하세요. 환경 보호 규칙을 구성하여 승인 및 아티팩트가 예상되는 경우에만 승인하세요. 인시던트 중에는 인지된 이유, 명시적 승인자, 타임스탬프, 그리고 추적 티켓이 필요할 수 있지만.
격리는 실패를 무시하는 권한이 아닙니다. 그것은 증거를 보존하면서 배달을 계속하는 제어된 방법입니다. 격리된 테스트가 보호된 릴리스 경로를 커버하는 경우 정책은 그것을 차단 상태로 복원하거나 승인 전에 위험 결정이 필요하도록 해야 합니다.
수용 체크리스트 및 장기적 신뢰성 관찰성
팀은 통합 테스트에서 일반적으로 두 가지 방식으로 실패합니다. 그들은 거대한 스위트로 시작하여 모든 병합을 느리게 하거나, 또는 mocks가 너무 광범위하여 실제 결제 노출된 실패를 테스트하지 않는 빠른 스위트를 만듭니다. 단계적 수용 계획은 두 가지 함정에서 벗어납니다.
Phase one, make the existing signal trustworthy
기존 pipeline에서 시작하세요:
- 첫 번째 게이트를 설정하세요: 중요한 서비스 계약을 식별하고 안정적인 체크만 차단하세요.
- 재시도 동작을 정의하세요: 대상화된 재실행을 허용하여 진단을 위해, 성공으로 변환되는 무성의 재시도가 발생하지 않도록 하세요.
- 병렬화 활성화: 도메인, 의존성, 또는 샤드에 따라 제한된 영역으로 테스트 스위트를 나누고, 각 작업에 고유한 데이터를 사용하여 격리하세요.
- 테스트 결과를 공개하세요: JUnit 보고서, 로그, 컨테이너 상태, 및 실패 분류를 모든 실행에 저장하세요.
이 단계에서는 최대의 커버리지 추구하지 마세요. 가장 비싼 소음의 원천을 제거한 후, 회복된 개발자 신뢰를 사용하여 실제 의존성 커버리지 확장하세요.
Phase two, increase environment fidelity
의존성 복제가 저렴한 경우 Testcontainers를 추가하세요. 서비스 소유권이 분산된 경우 계약 테스트를 소개하세요. 라우팅, 배포 구성, 또는 서비스 간 동작이 컴팩트한 작업에서 정확하게 표현되지 않는 경우 임시 환경을 사용하세요.
생산 장애가 마이그레이션 불일치로 노출된 경우 실제 데이터베이스 경로를 추가하세요. independently 배포된 서비스 간에 API이 drift한 경우 소비자-제공자 계약을 추가하세요. Kubernetes 구성에 의존하는 실패가 있는 경우 관련된 체크를 임시 네임스페이스에서 실행하세요.
Phase 3, 관찰성 연결
캡처 테스트 지속 시간 백분위수OpenTelemetry를 통해 환경 구성 차이, 잠금된 의존성 버전, 재시도-통과 비율, 그리고 관련된 애플리케이션 로그 및 트레이스.
- 불안정성 비율 증가 그래프: 어떤 스위트와 테스트가 더 이상 결정되지 않는지.
- 녹색으로 회복하기까지의 평균 시간: 실패한 pipeline가 회복하기까지의 시간을 얼마나 소비하는지.
- 실패 모드 클러스터: 실패, 환경, 의존성, 또는 테스트 설계와 관련된 code이 있는지.
- 수용고지품목: 어떤 테스트가 수용고지되었고, 그 테스트의 소유주가 누구이며, 그 테스트를 검토해야 할 때가 언제인지.
- 증빙자료: 각 환경 변경 전 각 게이트가 통과한 것을 나타내는 증빙자료.
이는 응용프로그램 관찰성의 기능입니다. 대시보드는 과거의 기록 아카이브가 아닙니다. 오늘의 결정에 영향을 미치는 테스트가 블록되거나 비동기적으로 기다리거나 수용고지되도록 해야 합니다.
블록된 서브셋, 수용고지 규칙, 환경 소유권, 재시도 제한, 아티팩트 요구 사항 및 오버라이드 프로세스를 포함하는 한 페이지 팀 정책을 유지하세요. 실패 데이터가 변경될 때마다 검토하세요. 단순히 주요 사고가 발생할 때만 대화할 필요는 없습니다.
Capgo은 웹 빌드 후에 signed live-update bundle 업로드를 자동화하는 CI/CD 통합을 제공합니다. Capgo은 feature-branch, 스테이징, 및 프로덕션 워크플로우를 지원하는 채널을 제공합니다. CapacitorJS 또는 Electron 팀이 제어된 모바일 배포와 통합 테스트 증빙을 연결해야 하는 경우, visit Capgo to evaluate the API and rollout workflow.
