CI/CD 통합 테스트: 병렬화, 게이트링 및 관찰성 최적화 가이드

결제 서비스 변경은 수천 개의 단위 테스트를 통과할 수 있지만, 결제 API가 idempotency key를 서비스가 예상하는 것과 다르게 해석할 수 있기 때문에 프로덕션에서 깨질 수 있습니다. 이 문제는 밤에 통합 작업이 인터페이스를 만날 때까지, 커밋이 파이프라인의 빠른 부분을 통과한 후에만 발견됩니다.

그것은 운영 문제의 CI/CD 통합 테스트. 단위 테스트는孤立된 논리가 올바르게 작동하는지 증명합니다. 통합 테스트는 구성 요소, 서비스, 스키마, 큐, 외부 의존성 등이 여전히 일치하는지 증명합니다. 현대적인 배포 PIPELINE에서 이러한 증거는 문제 해결 결정에 영향을 주어야 하며, 개발자가 무시하는 느린 검사로 변하지 않아야 합니다.

CI/CD는 소프트웨어 배포 모델로 주류가 된 것입니다. 2024년 mabl에서 발행한 DevOps 테스트 보고서 세계적인 조직의 거의 CI/CD 변환을 우선순위로 둔 조직의 테스터가 CI/CD 프로세스를 정의하고 유지하는 데 참여하는 50% CI/CD를 배포하지 않는 조직의 10% CI/CD 통합 검증은 배포 규모에서 작동해야 합니다.

목차

• CI/CD 통합 테스트의 제어점이 되는 이유
  • 제어점을 의도적으로 구축하십시오
• Integration Test는 Unit Test와 End to End Test 사이에 위치합니다.
  • Integration Test를 위한 세 가지 유용한 패턴
• 신뢰할 수 있는 테스트를 위해 환경과 데이터를 관리하는 방법
  • 재현 가능한 작업 순서
  • 특정한 목적을 가진 가상화 사용
• GitHub 액션을 위한 PipeLine 예시, GitLab CI, Jenkins
  • GitHub 액션
  • GitLab CI
  • Jenkins
• 불안정한 Integration Test를 위한 신뢰성 전략
  • 정책 변경하기 전에 측정
  • 일반적인 원인 제거
• 배포 정책 및 배포 승인 규칙
  • 스테이지별 게이트 사용
  • 바이스 패스 표시
• 장기 신뢰성을 위한 수용성 및 채택 체크리스트
  • 첫 번째 단계, 기존 신호의 신뢰성을 확립
  • 두 번째 단계, 환경의 신뢰성을 높여라
  • 세 번째 단계, 관찰성과 문제 해결을 연결

CI/CD에서 통합 테스트의 제어점

통합 테스트는 릴리스 위험을 구체화하는 곳입니다. 단위 테스트는 결제 처리기에서 idempotency key를 올바르게 형식화하는지 확인할 수 있지만, 통합 테스트만이 처리기, HTTP 클라이언트, 결제 API, 영구 저장소层, 그리고 재시도 동작이 함께 작동할 때 일치하는지 증명할 수 있습니다.

통합 테스트는 CI/CD pipeline 내에서 중요한 품질 제어점으로 작용합니다. 커밋은 단위 테스트가 통과했을 뿐만 아니라, 배포 가능하다고 간주되지 않습니다. 배포 승인을 받으려면, 변경된 인터페이스가 실제로 프로덕션 환경과 유사한 환경에서 작동하는지 증명해야 합니다.

The distinction matters because frequent integration without automated verification only moves defects faster. A systematic review of CI/CD improvement approaches identified recurring priorities that include reducing build and test time, improving visibility into results, supporting continuous testing, detecting faults, and improving deployment reliability. Another review in the same research record defines continuous integration around frequent code integration verified by an automated build that includes tests, so defects can be detected quickly.

제어점을 의도적으로 구축하십시오

CI/CD 통합 테스트를 분류하기 시작하십시오. 지원하는 결정에 따라:

• 차단 테스트 중요한 계약을 보호하고 병합 또는 승인 전에 동기적으로 실행하십시오.
• 격리된 테스트 불안정성을 조사하는 동안 배달을 막지 않으면서도 결과를 계속 생산하는 테스트입니다.
• 비동기 테스트 더 넓은 워크플로우, 전체 스테이징 구성, 또는 비용이 많이 드는 인프라를 실행하기 위해 커밋이 빠른 게이트를 통과한 후에.

이것은 모든 테스트가 'CI'에 있어야 하는지 여부를 논쟁하는 것보다 더 유용합니다. 올바른 질문은 특정 승인 결정에 영향을 미치는지 여부를 결정하는 테스트가 신뢰할 수 있고 가치 있는지 여부입니다.

실용적인 규칙: 안정적인 통합 증거에 게이트를 걸지 마십시오. 통합 스위트의 존재에 게이트를 걸지 마십시오.

이 구현의 나머지 부분은 그 규칙에서 따릅니다. 프로덕션과 같은 의존성을 사용하여 인터페이스가 실패할 수 있는 경우, 독립적인 체크를 병렬화하고, 가짜 실패를 측정하고, 격리 및 승진에 대한 명시적인 조건을 정의하세요. 이 작업을 더 광범위한 배포 관행과 연결하고 싶은 팀도 이 작업을 검토할 수 있습니다. 연속적 통합의 이점을 검토하세요..

단위 테스트와 종단 간 테스트 사이에 통합 테스트가 위치하는 곳입니다.

테스트 피라미드는 비용 모델이며 rigids 법칙이 아닙니다. 단위 테스트는 함수, 클래스 또는 모듈을 분리하여 빠르기 때문에 즉각적인 feedback를 제공합니다. 그러나 mocks는 시스템의 구멍에서 발생하는 정확히 실패를 숨길 수 있습니다. 예를 들어, 직렬화 차이, 데이터베이스 제약 조건, 인증 구성 또는 큐 동작과 같은.

종단 간 테스트는 사용자 경로를 전체 스택에서 실행하여 고위험 워크플로에 대한 가치가 있습니다. 또한 브라우저, 네트워크, 서비스 및 인프라 경계를 넘어 가며, 진단 및 안정성이 더 어려워집니다. 모든 병합이 종단 간의 모든 부품을 기다리면 개발자는 종종 더 집중된 API-레벨 통합 테스트보다 느린 신호를 받습니다.

통합 테스트는 중간 지대에 위치합니다. 실제 또는 근본적인 의존성을 사용하여 서비스 간의 동작을 검증할 수 있으며 완전한 UI 오케스트레이션을 요구하지 않습니다. layer는 HTTP 및 gRPC 호출, 큐 게시, 데이터베이스 마이그레이션, 캐시 상호 작용 및 스키마 호환성을 커버할 수 있습니다.

세 가지 유용한 통합 패턴

Testcontainers를 사용한 인스턴스 내 컴포넌트 테스트 응용 프로그램 컴포넌트와 종속성인 PostgreSQL, Redis, 또는 Kafka와 함께 시작합니다. 이 패턴은 영구성, 직렬화, 거래, 또는 브로커 의미론이 포함된 결함 위험이 있는 경우에 설정 비용이 가치 있는 패턴입니다. 테스트에 실제 종속성을 제공하면서 테스트 경계를 좁게 유지합니다.

Pact 또는 스키마 레지스트리를 사용한 크로스 서비스 계약 테스트 소비자와 제공자의 계약에 초점을 맞추어 서비스가独立적으로 릴리즈되고 계약 이탈에 대한 빠른 feedback이 필요할 때 강력한 선택입니다. 계약 테스트는 행동적 통합 테스트를 대체하지 않지만 공유 환경에 도달하기 전에 불일치한 인터페이스를 방지할 수 있습니다.

API-레벨 테스트 배포된 서비스를 통해 실제 네트워크 경로를 호출합니다. 경로 설정, 인증, 서비스 발견, 배포 구성, 또는 인프라 정책이 중요한 워크플로우에서 이 패턴을 사용합니다. 그러나 전체 스테이징 스택은 더 비싸고 실패할 때 분리하기 어려우므로 비즈니스 крит적 경로만 유지하세요.

동기화 병합 스위트를 의도적으로 좁게 유지하세요. 실용적인 목표는 통합 경로 10분 이내의 merge commit당, 그 다음에는 광범위한 시나리오를 비동기 실행으로 옮깁니다. 이 분할에 대한 더 광범위한 기초를 원하는 팀은 자동화된 테스트가 무엇을 포함하는지 살펴보세요., 그러나 통치 원칙은 간단합니다: 현실성을 지불할 때, 릴리스 결정이 변경되는 경우에만.

신뢰할 수 있는 테스트를 보장하기 위한 환경과 데이터 관리

wrong 환경에 실행되는 테스트는 오류 신뢰를 유발할 수 있습니다. 불안정한 공유 환경에 실행되는 테스트는 오류를 유발할 수 있습니다. 신뢰할 수 있는 CI/CD 통합 테스트 의존성 경계를 명확하게하고 데이터 상태를 재현할 수 있는 환경 전략이 필요합니다.

의존성이 신뢰할 수 있는 환경에서 실행될 수 있는지부터 시작하세요. Testcontainers는 각 작업에 대해 임시 PostgreSQL, Redis, Kafka 인스턴스를 제공할 수 있습니다. Docker 자체가 주요 이점이 아닙니다. 버전, 구성, 시작, 종료에 대한 제어권입니다.

재현 가능한 작업 순서

고정된 순서를 사용하여 테스트를 code 신뢰할 수 있는 환경에서 실행할 수 있도록 해보세요.

1. 실행 중인 종속성을 시작합니다. PostgreSQL 컨테이너를 부팅하고, 실제 헬스 체크 대신 실행 중인 프로세스가 트래픽을 수락할 준비가 되었는지 가정하지 말고 기다립니다.
2. 이주를 적용합니다. 애플리케이션에서 사용하는 동일한 이주 경로를 실행하십시오. 테스트 스키마를 수동으로 관리하는 것이 아니라, 프로덕션과 드리프트가 발생하지 않도록 하십시오.
3. 결정론적 FIXTURE를 로드합니다. scenario에 필요한 레코드만 시드하고, 각 작업에 고유한 데이터를 제공하여 병렬 실행이 서로의 상태를 변형하지 못하도록 하십시오.
4. 계약 확인을 실행합니다. 요청 형식, 응답 동작, 이벤트 스키마, 상태 전환 및 영구성 결과를 확인합니다.
5. 모든 것을 해체합니다. 테스트가 실패하더라도 테스트가 실패한 후에 다음 작업이 오염된 상태를 상속하지 않도록, 컨테이너와 임시 볼륨을 파괴하십시오.

90초의 PostgreSQL 부팅이 이주 및 트랜잭션 오류를 잡을 수 있는 합리적인 비용일 수 있습니다. 완전한 스테이징 클러스터는 다른 결정입니다. 더 많은 인프라를 소비하고, 더 많은 구성 드리프트를 유발하고, 실패의 원인이 될 수 있는 위치를 더 많이 증가시킵니다. 가장 좁은 충실한 환경에서 시작하고, 계약 커버리지 또는 프로덕션 사고가 더 작은 경계가 의미 있는 실패 모드를 누락하고 있음을 보여주면, 그 경계를 넓혀보십시오.

의도적인 가상화 사용

어떤 제 3 자 시스템은 모든 pipeline에서 안전하게 프로비저닝 될 수 없습니다. WireMock, Mountebank, Hoverfly는 의존성을 시뮬레이션 할 수 있지만, 시뮬레이션은 유지 관리 된 계약으로 다루어야 하며 편리한 탈출구가 아닙니다. ideal한 응답만 반환하는 mock는 인증 만료, 속도 제한, 잘못된 데이터 전송, 타임아웃 처리, 스키마 진화와 같은 것을 드러내지 않습니다.

임시 미리보기 환경은 여러 배포 된 서비스가 함께 작동할 때 위험에 대한 종속성이 있는 경우 유용합니다. Docker Compose는 compact한 로컬 및 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

Pinning 액션 및 의존성 버전은 환경 드리프트를 줄입니다. 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를 사용하는 팀에게는 자동화된 빌드 및 릴리즈와 GitHub Actions 이러한 모든 세 가지 실행자에서 중요한 설계 선택은 여전히 동일합니다: 비싼 모든 테스트를 동기화된 병목 현상으로 만들지 마십시오.

불안정한 통합 테스트에 대한 신뢰성 전략

실패를 진단하기 위한 용도로는 재시도는 유용하지만, 모든 테스트를 재시도하는 것은 신뢰성 향상을 위한 나쁜 전략입니다. 실제 결함을 가짜로 만들 수 있고, 환경 불안정성을 숨기고, 실제 PIPELINE 상태보다 보다 건강한 PASS-RATE 대시보드를 만들 수 있습니다.

이 문제의 규모는 공개된 엔지니어링 데이터에서 확인할 수 있습니다. Google은 약 16%의 테스트 에 대한 일부 불안정성과 약 1.5%의 모든 테스트 실행에서 불안정한 결과를 반환하는 경우가 있었고, 다른 연구에서는 Google 테스트 실패 중 약 4.56%가 불안정한 테스트로 인해 발생한 것으로 요약되어 있습니다. AWS 지속적 통합 및 배포 테스트 지침에서 요약되어 있습니다. . Google 데이터는 약 84%의 PASS-TO-FAIL CI 전환 이 불안정한 것보다 실제 버그가 아닌 것으로 나타났으며, Microsoft 프로젝트에서는 약retries are useful for diagnosis, but blanket retries are a poor reliability strategy. They can turn a real defect into a green build, hide environmental instability, and make pass-rate dashboards look healthier than the pipeline really is. The scale of the problem is visible in published engineering data. Google reported roughly 16% of tests with some flakiness and about 1.5% of all test runs returning a flaky result, while another study found 4.56% of Google test failures were caused by flaky tests, as summarized in the AWS continuous integration and delivery testing guidance . Google data also showed about 84% of pass-to-fail CI transitions were flaky rather than true bugs, and Microsoft projects reported about 4.6%의 불안정한 테스트 한 연구에 따르면, Panto에서 제공하는 불안정한 테스트 통계 리뷰에 따라

정책 변경하기 전에 측정하십시오

불안정성 추적하기:

불안정한 실패 ÷ 총 실행 횟수 × 100

7일에서 30일까지의 기간을 사용하십시오 그리고 suite, 테스트, 실행자 이미지, 의존성, 환경에 따라 계산하십시오. 한 실행자에서만 실패하는 테스트와 모든 환경에서 실패하는 테스트는 다른 해결책 문제입니다.이 분류를 사용하십시오:

제품 실패:

• 관련 게이트를 차단하고 __CAPGO_KEEP_0__ 또는 계약을 수정하십시오. block the relevant gate and fix the code or contract.
• 환경 오류: 보수 건강 검사, 자원 제한, 네트워킹, 또는 의존성 설정.
• 테스트 오류: 의문문 순서, 공유 상태, 타이밍, 정리, 또는 fixture 설계를 고치세요.
• 분류되지 않은 instabilty: 일시적으로 격리시키고, 소유주와 만료일을 할당하세요.

일반적인 원인 제거

공유 가변 상태는 순서 의존성을 만듭니다. 각 작업에 고유한 스키마, 고유한 식별자, 또는 트랜잭션 롤백 경계를 제공하세요. 비동기 시스템은 조건에 따라 폴링을 사용하세요. 시간 제한이 있는 폴링을 사용하세요. 대신 임의의 수면 시간을 사용하지 마세요. 만료 논리를 클록을 주입하고, 컨테이너의 건강을 기다리세요. 프로세스 시작 대신.

샤딩은 시간을 줄이지만, 나쁜 테스트를 고치지는 않습니다. 샤딩을 독립적으로 실행하고, 모든 샤드의 로그를 보존하세요. 오류 테스트 또는 샤드만 다시 실행하세요. 환경 오류가 하나의 통합 검사에만 발생한 경우 전체 pipeline을 다시 실행하지 마세요.

테스트는 환경에서 실행될 때 정의된 안정성 정책을 만족해야만 격리에서 풀 수 있습니다. 예를 들어, 연속적인 녹색 실행이 환경에서 실행될 때 테스트가 만족해야 합니다. 정확한 기준은 팀이 선택하고 기록해야 합니다. 중요한 것은 승진이 관찰된 안정성에 의해 얻어지는 것이며, 격리 레이블을 삭제하는 것이 아닙니다.

게이트 정책 및 배포 승진 규칙

품질 게이트는 다음 환경으로 이동할 수 있는 artifact가 충분한 신뢰할 수 있는 증거를 가지고 있는지 여부를 결정해야 합니다. 모든 테스트를 축적한 조직의 모든 테스트를 포함하는 곳이 되어서는 안 됩니다.

구현 불일치 cảnh告는 경고입니다. 2025년 조사에 의하면 Testkube의 CI/CD 테스트 분석 보고서에 따르면 72%의 조직 자동화된 QA가 CI/CD에 있습니다. 그러나 26% 테스트가 실패할 때 배포를 차단하는 품질 게이트를 설정하지 않습니다.

적용은 강제가 없이 이루어지면 배포 결정이 기억, 긴급성 또는 수동 체크리스트에 달려 있습니다.

단계별 게이트 사용

‘통과율’과 raw 퍼센티지 목표를 혼동하지 마세요. 테스트 스위트가 높은 통과율을 나타낼 수 있지만, 실제로 중요한 결제 또는 인증 경로에서 반복적으로 실패할 수 있습니다. 중요한 경로의 커버리지를 동작에 따라 정의하고, 그 체크를 결정적으로 통과하도록 요구하세요.

비활성화 경로를 표시하세요

branch 보호를 구성하여 실패하는 차단 체크가 병합을 방지하도록 하세요. 환경 보호 규칙을 구성하여 승인과 아티팩트가 예상되는 경우에만 제품 출시를 승인하세요. 인시던트 중에는 인지할 수 있는 오버라이드가 필요할 수 있지만, 명시적인 이유, 승인자 이름, 타임스탬프, 그리고 추후 티켓이 필요해야 합니다.

격리는 실패를 무시하는 권한이 아닙니다. 이는 배송을 계속하면서 증거를 보존하는 제어된 방법입니다. 격리된 테스트가 보호된 릴리스 경로를 포함한다면, 정책은 그것을 차단 상태로 복원하거나 승인 전 위험 결정이 필요하도록 해야 합니다.

채택 체크리스트 및 장기적인 신뢰의 관찰성

팀이 통합 테스트에서 실패하는 두 가지 일반적인 방법이 있습니다. 그들은 거대한 테스트 스위트로 시작하여 모든 병합을 느리게 하거나, 빠른 테스트 스위트를 만들어서 mocks가 너무 광범위하여 실제로 실패를 테스트하지 못하게 합니다. 단계적인 채택 계획은 두 가지 함정에서 벗어날 수 있습니다.

Phase one, make the existing signal trustworthy

기존 pipeline에서 시작하세요:

• 첫 번째 게이트를 설정하세요: 중요한 서비스 계약을 식별하고 안정적인 체크만 차단하세요.
• 재시도 동작을 정의하세요: 대상화된 재실행을 허용하여 진단을 위해, 성공으로 변환되는 무성의 재시도가 발생하지 않도록 하세요.
• 병렬화 기능을 활성화하세요: 도메인, 의존성, 또는 샤드에 따라 제한된 영역으로 테스트 스위트를 분할하고, 각 작업에 고유한 데이터를 사용하여 격리하세요.
• 테스트 결과를 공개하세요: JUnit 보고서, 로그, 컨테이너 상태, 및 실패 분류를 저장하세요.

이 단계에서는 최대의 커버리지에 집중하지 마세요. 가장 비싼 소음의 원천을 제거한 후, 회복된 개발자 신뢰를 사용하여 실제 의존성 커버리지 확장을 확장하세요.

Phase two, increase environment fidelity

의존성 복제가 저렴한 경우 Testcontainers를 추가하세요. 서비스 소유권이 분산된 경우 계약 테스트를 소개하세요. 라우팅, 배포 구성, 또는 서비스 간 동작이 컴팩트한 작업에서 정확하게 표현되지 않는 경우 임시 환경을 사용하세요.

생산 중단 사고가 데이터베이스 경로와의 일치하지 않는 마이그레이션을 노출한 경우 실제 데이터베이스 경로를 추가하세요. independently 배포된 서비스 간에 API이 드리프트한 경우 소비자-제공자 계약을 추가하세요. Kubernetes 구성에 의존하는 실패가 있는 경우 임시 네임스페이스에서 관련된 체크를 실행하는 대신 mock가 동일한 것을 증명한다고 가정하지 마세요.

세 번째 단계, 관찰 가능성을 연결하여 문제 해결을 시작하세요.

캡처 테스트 지속 시간 백분율OpenTelemetry를 통해 환경 구성 차이, 잠금된 의존성 버전, 재시도-통과 비율, 그리고 관련된 애플리케이션 로그 및 트레이스.

• 불안정한 테스트 비율 그래프: 어떤 스위트와 테스트가 더 이상 결정되지 않는지.
• 녹색으로 회복하기까지의 평균 시간: 실패한 pipeline이 회복하기까지의 시간을 얼마나 소비하는지.
• 실패 모드 클러스터: 실패가 code, 환경, 의존성, 또는 테스트 디자인과 관련되어 있는지.
• 감시 재고: 어떤 테스트가 감시되고, 그 테스트를 소유한 사람, 그리고 그 테스트를 검토해야 하는 시점입니다.
• 증빙 자료: 각 환경 변경 전 각 게이트가 통과한 것을 보여줍니다.

이것은 '응용 프로그램 관찰성'의 기능입니다. 대시보드는 과거의 기록 아카이브가 아닙니다. 오늘의 결정에 영향을 미치는 테스트가 블록되거나 비동기적으로 기다리거나 재감시되는지에 대한 결정이 반영되어야 합니다.블록된 서브셋, 감시 규칙, 환경 소유권, 재시도 제한, 아티팩트 요구 사항 및 오버라이드 프로세스를 포함하는 한 페이지 팀 정책을 유지하세요. 실패 데이터가 변경될 때마다 검토하세요. 단순한 사고로 인해 대화가 강제되는 경우만이 아닙니다.

__CAPGO_KEEP_0__은 웹 빌드 후에 signed live-update bundle 업로드를 자동화하는 CI/CD 통합을 제공합니다. __CAPGO_KEEP_0__은 feature branch, staging, 및 production 워크플로우를 지원하는 채널을 제공합니다. CapacitorJS 또는 Electron 팀이 통합 테스트 증거를 제어된 모바일 배포와 연결해야 하는 경우 __CAPGO_KEEP_0__을 방문하세요.

Capgo을 평가하고 배포 워크플로우를 구현하세요. Capgo to evaluate the API and rollout workflow.