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

DevOps Research and Assessment (DORA) metrics

DevOps Research and Assessment (DORA) 팀은 DevOps 성능을 메트릭하는 네 가지 지표를 확인했습니다. 이러한 지표를 사용하면 DevOps 효율성을 향상시키고 비즈니스 이해관계자에게 성능을 전달하여 비즈니스 결과를 가속화할 수 있습니다.

DORA에는 두 가지 핵심 영역으로 나뉜 네 가지 주요 지표가 포함되어 있습니다:

• 배포 빈도 및 변경의 리드 타임은 팀 속도를 메트릭합니다.
• 변경 실패율 및 서비스 복구 시간은 안정성을 메트릭합니다.

소프트웨어 리더들은 품질 지표와 함께 속도를 추적하여 품질을 희생하지 않고 빠른 속도로 제품을 제공하는지 확인할 수 있습니다.

비디오 설명은 DORA metrics: User analytics 및 GitLab speed run: DORA metrics를 참조하세요.

가치 스트림 분석에서의 DORA 지표

네 가지 DORA 지표는 가치 스트림 대시보드에 기본 제공됩니다. 이를 통해 엔지니어링 작업을 종단 간 가치 전달의 맥락에서 시각화할 수 있습니다.

One DevOps 플랫폼 가치 스트림 관리는 전체 소프트웨어 전달 수명 주기의 종단 간 가시성을 제공합니다. 이를 통해 팀과 관리자는 프로덕션성, 품질 및 전달의 모든 측면을 이해할 수 있으며 “도구 체인 부담” 없이 이를 달성할 수 있습니다.

배포 빈도

• GitLab 16.0에서 all 및 monthly 간격에 대한 빈도 계산 공식 수정됨.

배포 빈도는 지정된 기간(시간별, 일별, 주별, 월별, 또는 연간)에 대한 프로덕션으로의 성공적인 배포 빈도를 나타냅니다.

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

배포 빈도 계산 방법

GitLab에서 배포 빈도는 주어진 환경으로의 하루 평균 배포 횟수로 메트릭되며, 배포의 종료 시간(finished_at 속성)을 기반으로 합니다. GitLab은 주어진 날짜에 완료된 배포의 수에서 배포 빈도를 계산합니다. 성공적인 배포(Deployment.statuses = success)만이 카운트됩니다.

이 계산은 프로덕션 environment tier 또는 production/prod로 명명된 환경을 고려합니다. 환경은 그래프에 표시되기 위해서는 프로덕션 배포 티어에 속해야 합니다.

배포 빈도 향상 방법

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

• 자동화된 테스트 추가.
• 자동화된 코드 유효성 검사 추가.
• 변경 사항을 작은 반복으로 분할.

변경의 리드 타임

변경의 리드 타임은 코드 변경이 프로덕션으로 들어가기까지 걸리는 시간을 의미합니다.

변경의 리드 타임은 리드 타임과 같지 않습니다. 가치 스트림에서 리드 타임은 이슈에서 요청된 작업이 완료되고 배달(이슈가 닫힘)될 때까지 걸리는 시간을 메트릭합니다.

소프트웨어 리더들에게 변경의 리드 타임은 CI/CD 파이프라인의 효율성을 반영하고 얼마나 빨리 작업이 고객에게 전달되는지를 시각화합니다. 시간이 지날수록 변경의 리드 타임은 줄어들어야 하며, 팀의 성능은 증가해야 합니다. 낮은 변경의 리드 타임은 더 효율적인 CI/CD 파이프라인을 의미합니다.

변경의 리드 타임 계산 방법

GitLab은 변경의 리드 타임을 결합 요청을 프로덕션으로 성공적으로 전달하기까지 걸리는 시간(Merge 버튼이 클릭된 시점부터 코드가 성공적으로 프로덕션에서 실행되는 시간)을 기반으로 계산합니다. 이때 coding_time은 계산에 추가되지 않습니다. 데이터는 배포가 완료된 직후에 약간의 지연을 가지고 집계됩니다.

기본적으로 변경의 리드 타임은 단일 브랜치 작업만 지원하며(예: 기본 브랜치에서 개발, 스테이징, 프로덕션으로), 여러 배포 작업을 지원합니다. 따라서 Merge Request이 스테이징과 프로덕션에서 Merge되는 경우 GitLab은 하나가 아닌 두 개의 Merge Request으로 해석합니다.

변경의 리드 타임 개선 방법

첫 번째 단계는 그룹 및 프로젝트 간에 CI/CD 파이프라인의 효율성을 비교하는 것입니다. 그 후 다음을 고려해야 합니다:

• 프로세스에서 병목 현상을 식별하는 데 Value Stream Analytics 사용.
• 변경 사항을 작은 반복으로 분할.
• 자동화 추가.

서비스 복구 시간

서비스 복구 시간은 프로덕션에서의 장애로부터 조직이 회복하는 데 걸리는 시간을 의미합니다.

소프트웨어 리더들에게 서비스 복구 시간은 조직이 프로덕션에서의 장애로부터 회복하는 데 걸리는 시간을 반영합니다. 낮은 서비스 복구 시간은 조직이 혁신적인 새로운 기능에 대한 위험을 감수하여 경쟁 우위를 확보하고 비즈니스 결과를 증대할 수 있음을 의미합니다.

서비스 복구 시간 계산 방법

GitLab에서 서비스 복구 시간은 프로덕션 환경에서 장애가 열려 있었던 중앙값으로 메트릭됩니다. GitLab은 주어진 기간 내에 프로덕션 환경에서 장애가 열려 있었던 시간(초)을 계산합니다. 이는 다음을 전제로 합니다:

• GitLab 장애가 추적되고 있음.
• 모든 장애가 프로덕션 환경과 관련되어 있음.
• 장애와 배포가 엄격하게 일대일 관계를 가지고 있음. 장애는 단 하나의 프로덕션 배포와 관련되어 있으며, 프로덕션 배포는 하나 이상의 장애와 관련되어 있지 않음.

서비스 복구 시간 개선 방법

첫 번째 단계는 그룹 및 프로젝트 간에 서비스 중단 및 장애로부터의 회복 시간을 벤치마킹하는 것입니다. 그 후 다음을 고려해야 합니다:

• 프로덕션 환경에 대한 가시성 개선.
• 응답 워크플로우 개선.

변경 실패율

변경 실패율은 변경이 프로덕션에서 실패를 일으키는 빈도를 나타냅니다.

소프트웨어 리더들은 변경 실패율 지표를 사용하여 출시되는 코드의 품질에 대한 통찰을 얻을 수 있습니다. 높은 변경 실패율은 비효율적인 배포 프로세스나 부족한 자동화된 테스트 커버리지를 나타낼 수 있습니다.

변경 실패율 계산 방법

GitLab에서 변경 실패율은 주어진 기간에 프로덕션에서 장애를 발생시키는 배포의 비율로 메트릭됩니다. GitLab은 변경 실패율을 프로덕션 환경으로의 배포 횟수로 나누어 계산합니다. 이 계산은 다음을 가정합니다:

• GitLab 장애가 추적되고 있음.
• 모든 장애가 환경과 관계없이 프로덕션 장애임.
• 변경 실패율은 주로 고수준 안정성 추적으로 사용되며, 그룹화된 일일 비율로 모든 장애 및 배포가 집계됩니다. 배포와 장애 사이의 구체적인 관계는 issue 444295에서 제안됩니다.

예를 들어, 하루에 10번의 배포(하루에 한 번 배포하는 것으로 가정) 중 첫 번째 날에 장애가 두 건, 마지막 날에 장애가 한 건 있다면 변경 실패율은 0.3입니다.

변경 실패율 향상 방법

첫 번째 단계는 그룹 및 프로젝트 간에 품질과 안정성을 벤치마킹하는 것입니다. 그 후 다음을 고려해야 합니다:

• 안정성과 처리량(Deployment frequency 및 Lead time for changes) 사이의 적절한 균형을 찾고, 속도를 위해 품질을 희생하지 않음.
• 코드 검토 프로세스의 효능 향상.
• 자동화된 테스팅 추가.

DORA 사용자 정의 계산 규칙

• GitLab 15.4에서 dora_configuration이라는 플래그로 도입. 기본 설정은 비활성화됨. 이 기능은 Experiment입니다.

변경 사항의 리드 타임에 대한 다중 브랜치 규칙

기본적인 변경 사항의 리드 타임 계산과 달리, 이 계산 규칙은 각 작업에 대해 단일 배포 작업으로 다중 브랜치 작업을 메트릭할 수 있도록 합니다. 예를 들어, 개발 브랜치에서 개발 작업, 스테이징 브랜치에서 스테이징 작업, 프로덕션 브랜치에서 프로덕션 작업까지입니다.

이 계산 규칙은 개발 흐름의 일부인 대상 브랜치에서 dora_configurations 테이블을 업데이트하여 구현되었습니다. 이렇게 함으로써, GitLab은 브랜치를 하나로 인식하고 다른 Merge Request을 필터링할 수 있습니다.

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

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

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

Dora::Configuration.create!(project: my_project, branches_for_lead_time_for_changes: ['master', 'main'])

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 explorer를 사용하여 GraphQL API 리소스를 탐색할 수 있습니다.

DORA 지표 메트릭

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

배포 빈도는 일반적인 푸시 기반 배포를 위해 생성된 배포 레코드를 기반으로 계산됩니다. 이러한 배포 레코드는 컨테이너 이미지가 에이전트와 함께 GitLab에 연결될 때와 같이 풀 요청 기반 배포에 대해 생성되지 않습니다.

이러한 경우 DORA 지표를 추적하기 위해 배포 레코드를 생성하여야 합니다. 배포 레코드에서는 배포가 구성된 환경 이름을 설정해야 합니다. 왜냐하면 티어 변수는 배포가 아닌 특정 환경에 대해 지정되기 때문입니다. 자세한 내용은 외부 배포 도구의 배포를 추적을 참조하세요.

Jira를 사용한 DORA 지표 메트릭

• 배포 빈도 및 변경 사항의 리드 타임은 GitLab CI/CD 및 Merge Request(MRs)을 기반으로 계산되며 Jira 데이터가 필요하지 않습니다.
• 시간 복원 및 변경 실패율은 계산을 위해 GitLab 사건이 필요합니다. 자세한 내용은 외부 사건을 사용하여 DORA 시간 복원 및 변경 실패율 메트릭 및 Jira 사건 복제기 안내를 참조하세요.

외부 사건으로 DORA 시간 복원 서비스 및 변경 실패율 메트릭

PagerDuty의 경우, 각 PagerDuty 사건마다 GitLab 사건을 자동으로 생성하기 위한 웹훅을 설정할 수 있습니다. 이 구성에는 PagerDuty 및 GitLab에서 변경을 수행해야 합니다.

다른 사건 관리 도구의 경우, HTTP 통합을 설정하고 자동으로 다음을 수행할 수 있습니다.

1. 경보가 작동될 때 사건 생성.
2. 회복 경보를 통한 사건 자동 닫기.

GitLab의 DORA 지표

GitLab은 다음과 같은 DORA 지표를 지원합니다:

모든 메트릭은 (DORA) 주요 메트릭 API에서 사용할 수 있습니다.

DORA 지표 차트

DORA 지표는 다음 차트에 표시됩니다:

• 가치 스트림 대시보드, 이는 트렌드, 패턴 및 개선 기회를 식별하는 데 도움이 되며, DORA 지표가 지표 비교 패널 및 DORA 수행자 점수 패널에 표시됩니다.
• CI/CD 분석 차트, 이는 파이프라인 성공률 및 기간, 지난 DORA 지표의 히스토리를 표시합니다.
• 그룹 및 프로젝트에 대한 통찰 보고서, 여기서는 DORA 질의 매개변수를 사용하여 사용자 정의 차트를 만들 수도 있습니다.

DORA 지표 데이터 집계

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