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

DevOps Research and Assessment (DORA) metrics

• GitLab 13.7에 도입되었습니다.
• 변경의 리드 타임은 GitLab 13.10에 도입되었습니다.

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

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

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

소프트웨어 리더들은 품질 메트릭과 함께 속도를 추적하여 품질을 희생하지 않도록 할 수 있습니다.

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

가치 스트림 분석에서의 DORA 메트릭

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

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

배포 빈도

• GitLab 16.0에서 ‘모두’ 및 ‘월간’ 간격의 빈도 계산 공식에 대한 수정이 도입되었습니다.

배포 빈도는 주어진 기간(시간당, 매일, 주간, 월간 또는 연간)에 대한 프로덕션으로의 성공적인 배포의 빈도입니다.

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

배포 빈도가 어떻게 계산되는가

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

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

배포 빈도를 개선하는 방법

첫 번째 단계는 그룹 및 프로젝트 간의 코드 릴리스 주기를 기준으로 하는 것입니다. 다음으로는 다음을 고려해야 합니다:

• 자동화된 테스트 추가.
• 자동화된 코드 유효성 검사 추가.
• 변경 사항을 작은 단위로 분할하기.

변경의 리드 타임

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

변경의 리드 타임은 리드 타임과는 다릅니다. 가치 스트림에서 리드 타임은 이슈에 대한 작업이 요청된 순간(이슈 생성)부터 이행되어 전달된 순간(이슈 완료)까지의 시간을 메트릭합니다.

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

변경의 리드 타임이 어떻게 계산되는가

GitLab은 변경의 리드 타임을 Merge Request Merge 시간(Merge 버튼을 클릭한 때)부터 코드가 프로덕션에서 성공적으로 실행될 때까지의 시간, 즉 coding_time을 계산에 추가하지 않고 메트릭합니다. 데이터는 배포가 완료된 후 즉시 집계되며 약간의 지연이 있습니다.

기본적으로 변경의 리드 타임은 하나의 브랜치 작업 및 다중 배포 작업(예: 개발에서 스테이징으로, 기본 브랜치의 프로덕션으로)을 지원합니다. 스테이징에서 Merge Request을 Merge하고, 그런 다음 프로덕션에서 Merge Request을 Merge할 때 GitLab은 하나가 아닌 두 배포된 Merge Request으로 해석합니다.

변경의 리드 타임을 개선하는 방법

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

• 가치 스트림 분석을 사용하여 프로세스의 병목 현상 식별.
• 변경 사항을 작은 단위로 분할하기.
• 자동화 추가.

서비스 복원 시간

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

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

서비스 복원 시간이 어떻게 계산되는가

GitLab에서 서비스 복원 시간은 프로덕션 환경에서 발생한 사고가 열려 있었던 시간의 중간값으로 메트릭됩니다. GitLab은 주어진 기간에 프로덕션 환경에서 사고가 열려 있었던 시간(초)을 계산합니다. 이에는 다음 사항이 포함됩니다:

• GitLab 사고가 추적됩니다.
• 모든 사고가 프로덕션 환경과 관련되어 있습니다.
• 사고와 배포는 엄격한 1:1 관계를 갖습니다. 사고는 단 하나의 프로덕션 배포와 관련되며, 어떤 프로덕션 배포도 둘 이상의 사고와 관련되지 않습니다.

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

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

• 프로덕션 환경의 가시성 향상.
• 응답 워크플로우 개선.

변경 실패율

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

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

변경 실패율의 계산 방법

GitLab에서 변경 실패율은 특정 기간 내 프로덕션에서 사건을 일으키는 배포의 백분율로 메트릭됩니다. GitLab은 변경 실패율을 사건 수를 프로덕션 환경으로의 배포 수로 나눈 것으로 계산합니다. 이 계산은 다음을 전제로 합니다:

• GitLab 사건이 추적됩니다.
• 모든 사건이 환경과 무관하게 프로덕션 사건으로 간주됩니다.
• 변경 실패율은 주로 고수준 안정성 추적에 사용되므로 특정 날에 모든 사건과 배포가 결합된 일일률로 집계됩니다. 배포와 사건 사이의 구체적인 관계는 이슈 444295에서 제안됩니다.

예를 들어, 첫 날에 2건의 사건이 발생하고 마지막 날에 1건의 사건이 발생하는 10건의 배포(하루에 한 건의 배포를 고려)의 경우, 변경 실패율은 0.3입니다.

변경 실패율 개선 방법

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

• 안정성과 처리량(배포 빈도 및 변경 대기 시간) 사이의 적절한 균형을 찾고 품질을 속도에 희생시키지 않는 것입니다.
• 코드 리뷰 프로세스의 효과를 향상시키기
• 자동화된 테스트 추가.

DORA 사용자 정의 계산 규칙

• GitLab 15.4에서 플래그dora_configuration라는 이름의 플래그로 함께 소개되었습니다. 기본적으로 비활성화됩니다. 이 기능은 시험입니다.

이 기능은 시험입니다. 이 기능을 테스트하는 사용자 디렉터리에 참여하려면 여기에 제안된 테스트 흐름을 확인하세요. 버그를 발견하면 여기에 이슈를 엽니다. 사용 사례와 피드백을 공유하려면 epic 11490에 댓글을 달아 주세요.

변경 대기 시간을 위한 다중 브랜치 규칙

기본 변경 대기 시간 계산과 달리, 이 계산 규칙은 단일 배포 작업으로 다중 브랜치 작업을 메트릭할 수 있게 합니다. 예를 들어 개발 브랜치에서 개발 작업부터 스테이징 브랜치에서 스테이징 작업, 프로덕션 브랜치에서 프로덕션 작업까지입니다.

이 계산 규칙은 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(
        metric: DEPLOYMENT_FREQUENCY
        startDate: "2023-12-01"
        endDate: "2024-02-01"
        interval: MONTHLY
      ) {
        date
        value
      }
    }
  }
}

대화식 GraphQL 탐색기를 사용하여 GraphQL API 리소스를 탐색할 수 있습니다.

DORA 지표 메트릭

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

배포 빈도는 전형적인 푸시 기반 배포를 위해 생성된 배포 레코드를 기반으로 계산됩니다. 이러한 배포 레코드는 예를 들어 컨테이너 이미지가 에이전트와 연결된 경우와 같이 풀 기반 배포의 경우에는 생성되지 않습니다.

이러한 경우 DORA 지표를 추적하려면 Deployments API를 사용하여 배포 레코드를 생성할 수 있습니다. 배포된 환경을 설정해야 하며, 배포에 대한 티어 변수는 배포가 아니라 해당 환경을 고려해야 합니다. 자세한 내용은 외부 배포 도구의 배포 추적를 참조하세요.

Jira를 사용하여 DORA 지표 메트릭

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

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

PagerDuty의 경우 각 PagerDuty 사건마다 GitLab 사건을 자동으로 생성하도록 웹훅을 설정할 수 있습니다. 이 구성에는 PagerDuty와 GitLab 양쪽에서 변경해야 할 사항이 있습니다.

기타 사건 관리 도구의 경우 HTTP 통합을 설정하여 다음을 자동화할 수 있습니다:

1. 알림이 트리거될 때 사건을 생성.
2. 회복 알림을 통해 사건 닫기.

GitLab의 DORA 지표

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

DORA 지표 차트

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

• Value Streams 대시보드, 여기에서 추세, 패턴 및 개선 기회를 식별하는 데 도움이 됩니다. DORA 지표는 지표 비교 패널과 DORA 수행자 점수 패널 에 표시됩니다.
• CI/CD 분석 차트, 파이프라인 성공률과 기간, 그리고 DORA 지표의 역사를 보여줍니다.
• 그룹 및 프로젝트에 대한 인사이트 보고서, 여기에서 DORA 쿼리 매개변수를 사용하여 사용자 정의 차트를 만들 수도 있습니다.

DORA 지표 데이터 집계

아래 표는 다른 차트에서 DORA 지표의 데이터 집계 개요를 제공합니다.