• GitLab의 DORA 메트릭
• 배포 빈도
  • 배포 빈도 예측
  • 배포 빈도 계산 방법
  • 배포 빈도 향상 방법
• 변경 사항의 리드 타임
  • 변경 사항의 리드 타임 계산 방법
  • 변경 사항의 리드 타임 향상 방법
• 서비스 복구 시간
  • 서비스 복구 시간 계산 방법
  • 서비스 복구 시간을 개선하는 방법
• 변경 실패율
  • 변경 실패율 계산 방법
  • 변경 실패율 개선 방법
• DORA 사용자 정의 계산 규칙
  • 변경에 대한 리드 타임을 위한 다중 브랜치 규칙
• DORA 메트릭 데이터 검색
• DORA 메트릭 측정
  • GitLab CI/CD 파이프라인을 사용하지 않고 DORA 메트릭 측정
  • Jira와 함께 DORA 메트릭 측정
  • 외부 인시던트를 사용한 DORA 서비스 복구 시간 및 변경 실패율 측정
• DORA 메트릭 가용성
  • DORA 메트릭 데이터 집계

DevOps 연구 및 평가(DORA) 메트릭

DevOps 연구 및 평가(DORA) 팀은 DevOps 성능을 측정하는 네 가지 메트릭을 확인했습니다.

이 메트릭을 사용하면 DevOps 효율성을 개선하고 비즈니스 이해관계자에게 성과를 전달할 수 있어 비즈니스 결과를 가속화할 수 있습니다.

DORA는 두 가지 핵심 DevOps 영역으로 나뉜 네 가지 주요 메트릭을 포함합니다:

• 배포 빈도 및 변경 소요 시간은 팀의 속도를 측정합니다.
• 변경 실패율 및 서비스 복구 시간은 안정성을 측정합니다.

소프트웨어 리더는 품질 메트릭과 함께 속도를 추적하여 품질을 속도와 바꾸지 않도록 보장합니다.

비디오 설명은 DORA 메트릭: 사용자 분석 및 GitLab 스피드런: DORA 메트릭을 참조하세요.

GitLab의 DORA 메트릭

GitLab은 다음의 분석 기능에서 사용할 수 있는 DORA 메트릭에 대한 다양한 분석 및 인사이트를 제공합니다:

• Value Streams 대시보드에서의 DORA 메트릭은 기본 제공되며 추세, 패턴, 개선 기회를 식별하는 데 도움이 됩니다. 이러한 메트릭은 메트릭 비교 패널 및 DORA 수행자 점수 패널에 표시됩니다.
• CI/CD 분석 차트에서의 DORA 메트릭은 파이프라인 성공률 및 소요 시간, DORA 메트릭의 변화를 보여줍니다.
• Insights 보고서에서의 DORA 메트릭은 DORA 쿼리 매개변수를 사용하여 맞춤형 차트를 만들 수 있습니다.
• (DORA) 주요 메트릭 API는 모든 메트릭을 포함합니다.

배포 빈도

• 도입됨 GitLab 16.0에서 all 및 monthly 간격의 빈도 계산 공식을 수정했습니다.

배포 빈도는 주어진 날짜 범위(시간별, 일별, 주별, 월별 또는 연간)에서 프로덕션에 성공적으로 배포된 빈도입니다.

소프트웨어 리더는 배포 빈도 메트릭을 통해 팀이 소프트웨어를 프로덕션에 성공적으로 배포하는 빈도와 팀이 고객 요청이나 새로운 시장 기회에 얼마나 빨리 대응할 수 있는지를 이해할 수 있습니다.
높은 배포 빈도는 더 빨리 피드백을 받고 개선 사항 및 기능을 제공하기 위해 더 빠르게 반복할 수 있음을 의미합니다.

배포 빈도 예측

배포 빈도 예측(구 Value stream forecasting)은 통계적 예측 모델을 사용하여 생산성 메트릭을 예측하고 소프트웨어 개발 주기 전반에 걸쳐 이상 현상을 식별합니다.
이 정보는 제품 및 팀에 대한 계획 및 의사 결정을 개선하는 데 도움이 될 수 있습니다.

Value stream forecasting에 대한 개요를 시청하세요.

배포 빈도 계산 방법

GitLab에서 배포 빈도는 특정 환경으로 하루 동안의 평균 배포 횟수로 측정되며, 배포의 종료 시간(finished_at 속성)을 기준으로 합니다.

GitLab은 주어진 날짜의 완료된 배포 수를 기준으로 배포 빈도를 계산합니다. 성공적인 배포(Deployment.statuses = success)만 포함됩니다.

계산은 생산 environment tier 또는 production/prod라는 이름의 환경을 고려합니다. 환경은 그래프에 배포 정보가 나타나기 위해 생산 배포 계층의 일부여야 합니다.

다른 환경에 대한 DORA 지표를 구성할 수 있으며, 이는 .gitlab/insights.yml 파일에서 environment_tiers 매개변수 아래에 other를 지정하여 가능합니다.

배포 빈도 향상 방법

첫 번째 단계는 그룹 및 프로젝트 간의 코드 릴리스 간격을 벤치마킹하는 것입니다. 다음 사항을 고려해야 합니다:

• 자동화된 테스트 추가.
• 자동화된 코드 검증 추가.
• 변경 사항을 더 작은 반복으로 분할하기.

변경 사항의 리드 타임

변경 사항의 리드 타임은 코드 변경 사항이 생산 환경에 반영되는 데 걸리는 시간입니다.

변경 사항의 리드 타임은 리드 타임과 동일하지 않습니다. 가치 흐름에서 리드 타임은 이슈에 대한 작업이 요청된 순간(이슈 생성)부터 이행되고 전달되는 순간(이슈 닫힘)까지 걸리는 시간을 측정합니다.

소프트웨어 리더에게 변경 사항의 리드 타임은 CI/CD 파이프라인의 효율성을 반영하며, 고객에게 작업이 얼마나 빨리 전달되는지를 시각화합니다.

시간이 지남에 따라 변경 사항의 리드 타임은 감소해야 하며, 팀의 성과는 증가해야 합니다. 낮은 변경 사항의 리드 타임은 더 효율적인 CI/CD 파이프라인을 의미합니다.

변경 사항의 리드 타임 계산 방법

GitLab은 병합 요청을 생산 환경에 성공적으로 배포하는 데 걸린 초 수를 기준으로 변경 사항의 리드 타임을 계산합니다: 병합 요청 병합 시간(병합 버튼 클릭 시)부터 코드가 생산에서 성공적으로 실행되는 시점까지 계산하며, coding_time을 계산에 추가하지 않습니다. 데이터는 배포가 완료된 직후 약간의 지연과 함께 집계됩니다.

기본적으로 변경 사항의 리드 타임은 여러 배포 작업이 있는 단일 브랜치 작업만 측정하는 것을 지원합니다(예: 기본 브랜치의 개발에서 스테이징, 스테이징에서 프로덕션). 병합 요청이 스테이징에서 병합되고, 그 후 프로덕션에서 병합되면 GitLab은 이를 하나의 배포된 병합 요청이 아닌 두 개의 배포된 병합 요청으로 해석합니다.

변경 사항의 리드 타임 향상 방법

첫 번째 단계는 그룹 및 프로젝트 간의 CI/CD 파이프라인 효율성을 벤치마킹하는 것입니다. 다음 사항을 고려해야 합니다:

• Value Stream Analytics를 사용하여 프로세스의 병목 현상을 식별하기.
• 변경 사항을 더 작은 반복으로 나누기.
• 자동화 추가.

서비스 복구 시간

서비스 복구 시간은 조직이 생산 환경에서 실패에서 복구되는 데 걸리는 시간입니다.

소프트웨어 리더에게 서비스 복구 시간은 조직이 생산 환경에서 실패에서 회복되는 데 걸리는 시간을 반영합니다.

낮은 서비스 복구 시간은 조직이 신규 혁신적 기능으로 위험을 감수하여 경쟁 우위를 확보하고 비즈니스 성과를 높일 수 있음을 의미합니다.

서비스 복구 시간 계산 방법

GitLab에서 서비스 복구 시간은 생산 환경에서 사건이 열린 중앙값으로 측정됩니다.

GitLab은 특정 기간 내에 생산 환경에서 사건이 열린 초 수를 계산합니다. 이는 다음을 가정합니다:

• GitLab 사건이 추적됩니다.
• 모든 사건은 생산 환경과 관련이 있습니다.
• 사건과 배포는 엄격하게 일대일 관계를 가집니다. 하나의 사건은 오직 하나의 생산 배포와 관련이 있으며, 모든 생산 배포는 최대 하나의 사건에만 관련됩니다.

서비스 복구 시간을 개선하는 방법

첫 번째 단계는 팀의 응답과 서비스 중단 및 장애에서 회복하는 시간을 벤치마킹하는 것입니다. 다음으로 고려해야 할 사항은 다음과 같습니다:

• 프로덕션 환경에 대한 관찰 가능성 향상.
• 응답 워크플로우 개선.

변경 실패율

변경 실패율은 변경이 프로덕션에서 실패를 유발하는 빈도입니다.

소프트웨어 리더는 변경 실패율 메트릭을 사용하여 배포되는 코드의 품질에 대한 통찰력을 얻을 수 있습니다.

높은 변경 실패율은 비효율적인 배포 프로세스 또는 자동화된 테스트 커버리지가 부족함을 나타낼 수 있습니다.

변경 실패율 계산 방법

GitLab에서 변경 실패율은 주어진 기간 동안 프로덕션에서 사건을 유발하는 배포의 비율로 측정됩니다.

GitLab은 변경 실패율을 프로덕션 환경에 대한 배포 수로 나눈 사건 수로 계산합니다. 이 계산은 다음을 전제로 합니다:

• GitLab 사건이 추적됩니다.
• 모든 사건은 환경에 관계없이 프로덕션 사건입니다.
• 변경 실패율은 주로 높은 수준의 안정성 추적을 위해 사용됩니다. 그래서 특정 일자에 모든 사건과 배포가 결합된 일일 비율로 집계됩니다. 배포와 사건 간의 특정 관계를 추가하는 것은 문제 444295에서 제안되었습니다.

예를 들어, 만약 첫 번째 날에 두 사건과 마지막 날에 한 사건이 있는 하루에 한 배포를 고려하면, 배포 수가 10인 경우 당신의 변경 실패율은 0.3입니다.

변경 실패율 개선 방법

첫 번째 단계는 그룹과 프로젝트 간의 품질과 안정성을 벤치마킹하는 것입니다. 다음으로 고려해야 할 사항은 다음과 같습니다:

• 안정성과 처리량(배포 빈도 및 변경에 대한 리드 타임) 사이의 적절한 균형을 찾고, 품질을 희생하지 않도록 하세요.
• 코드 리뷰 프로세스의 효율성 향상.
• 자동화된 테스트 추가.

DORA 사용자 정의 계산 규칙

• 도입됨 GitLab 15.4에서 dora_configuration라는 플래그와 함께. 기본값으로 비활성화 되어 있습니다. 이 기능은 실험입니다.

이 기능은 실험입니다.
이 기능을 테스트하는 사용자 목록에 참여하려면, 여기에서 제안된 테스트 흐름을 확인하세요.
버그를 발견하면, 여기에 문제를 열어주세요.
사용 사례 및 피드백을 공유하려면, 에픽 11490에 댓글을 남겨주세요.

변경에 대한 리드 타임을 위한 다중 브랜치 규칙

기본 변경에 대한 리드 타임 계산과 달리, 이 계산 규칙은 각 작업에 대한 단일 배포 작업으로 다중 브랜치 작업을 측정할 수 있도록 합니다.
예를 들어, 개발 브랜치에서 개발 작업을 수행한 후 스테이징 브랜치에서 스테이징 작업을 수행하고, 마지막으로 프로덕션 브랜치에서 프로덕션 작업을 수행하는 방식입니다.

이 계산 규칙은 개발 흐름의 일부인 대상 브랜치로 dora_configurations 테이블을 업데이트하여 구현되었습니다.
이렇게 하면 GitLab이 브랜치를 하나로 인식하고 다른 병합 요청을 필터링할 수 있습니다.

이 구성은 선택한 프로젝트에 대한 일일 DORA 메트릭의 계산 방식을 변경하지만 다른 프로젝트, 그룹, 사용자에게는 영향을 미치지 않습니다.

이 기능은 프로젝트 수준의 전파만 지원합니다.

이를 위해 Rails 콘솔에서 다음 명령을 실행하세요:

my_project = Project.find_by_full_path('group/subgroup/project')
Dora::Configuration.create!(project: my_project, branches_for_lead_time_for_changes: ['master', 'main'])

기존 구성을 업데이트하려면, 다음 명령을 실행하세요:

my_project = Project.find_by_full_path('group/subgroup/project')
record = Dora::Configuration.where(project: my_project).first
record.branches_for_lead_time_for_changes = ['development', 'staging', 'master', 'main']
record.save!

DORA 메트릭 데이터 검색

DORA 데이터를 검색하려면 GraphQL 또는 REST API를 사용하세요.

다음 예에서는 GraphQL API를 사용하여 주어진 기간에 대한 월별 배포 빈도를 검색합니다:

{
  project(fullPath: "gitlab-org/gitlab") {
    dora {
      metrics(
        startDate: "2023-12-01"
        endDate: "2024-01-31"
        interval: MONTHLY
      ) {
        date
        deploymentFrequency
        leadTimeForChanges
        timeToRestoreService
        changeFailureRate
      }
    }
  }
}

인터랙티브 GraphQL 탐색기를 사용하여 GraphQL API 리소스를 탐색할 수 있습니다.

DORA 메트릭 측정

GitLab CI/CD 파이프라인을 사용하지 않고 DORA 메트릭 측정

배포 빈도는 전형적인 푸시 기반 배포를 위해 생성된 배포 기록을 기반으로 계산됩니다.

이러한 배포 기록은 컨테이너 이미지가 에이전트로 GitLab에 연결될 때와 같은 풀 기반 배포에 대해서는 생성되지 않습니다.

이 경우 DORA 메트릭을 추적하려면 Deployments API를 사용하여 배포 기록을 생성할 수 있습니다.

배포 계층이 구성된 환경 이름을 설정해야 합니다. 계층 변수는 배포가 아니라 주어진 환경에 대해 지정됩니다.

자세한 내용은 외부 배포 도구의 배포 추적을 참조하세요.

Jira와 함께 DORA 메트릭 측정

• 배포 빈도 및 변경을 위한 리드 타임은 GitLab CI/CD 및 Merge Requests(MRs)를 기반으로 계산되며, Jira 데이터를 요구하지 않습니다.

• 서비스 복구 시간 및 변경 실패율은 계산을 위해 GitLab 인시던트가 필요합니다.

자세한 내용은 외부 인시던트로 서비스 복구 시간 및 변경 실패율 측정 및 Jira 인시던트 복제기 가이드를 참조하세요.

외부 인시던트를 사용한 DORA 서비스 복구 시간 및 변경 실패율 측정

PagerDuty의 경우, 각 PagerDuty 인시던트에 대해 GitLab 인시던트를 자동으로 생성하기 위해 웹훅을 설정할 수 있습니다.

이 구성을 위해서는 PagerDuty와 GitLab 모두에서 변경을 해야 합니다.

다른 인시던트 관리 도구의 경우, HTTP 통합을 설정하고 이를 사용하여 자동으로:

1. 알림이 발생할 때 인시던트 생성.
2. 복구 알림을 통해 인시던트 닫기.

DORA 메트릭 가용성

아래 표는 프로젝트 및 그룹에서 DORA 메트릭의 가용성 개요를 제공합니다:

DORA 메트릭 데이터 집계

아래 표는 다양한 차트에서 DORA 메트릭의 데이터 집계를 개관합니다.