InfoGrab Docs

Value Stream 분석

요약

Value stream 분석은 소프트웨어 개발 프로세스의 모든 단계 기간을 계산합니다. Value stream 분석을 사용하여 다음을 식별합니다: Value stream 분석은 비즈니스에 도움을 줍니다: 클릭 가능한 데모는 Value Stream Management 제품 투어를 참조하세요.

Value stream 분석은 소프트웨어 개발 프로세스의 모든 단계 기간을 계산합니다. 머지 리퀘스트 또는 이슈 이벤트를 추적하여 아이디어에서 프로덕션까지 얼마나 걸리는지 측정할 수 있습니다.

Value stream 분석을 사용하여 다음을 식별합니다:

  • 아이디어에서 프로덕션까지 걸리는 시간.
  • 특정 프로젝트의 속도.
  • 개발 프로세스의 병목 현상.
  • 오래 실행되는 이슈 또는 머지 리퀘스트.
  • 소프트웨어 개발 라이프사이클을 느리게 만드는 요인.

Value stream 분석은 비즈니스에 도움을 줍니다:

  • 종단간 DevSecOps 워크스트림 시각화.
  • 비효율성 식별 및 해결.
  • 더 많은 가치를 더 빠르게 제공하기 위한 워크스트림 최적화 (예: 머지 리퀘스트 리뷰 시간 단축).

클릭 가능한 데모는 Value Stream Management 제품 투어를 참조하세요.

Value stream 분석은 계층적 구조를 가집니다:

  • Value stream은 value stream Stage 목록을 포함합니다.
  • 각 value stream Stage 목록은 하나 이상의 Stage를 포함합니다.
  • 각 Stage는 두 개의 이벤트로 정의됩니다: 시작과 종료.

Value stream#

Value stream은 고객에게 가치를 전달하는 전체 업무 프로세스입니다. Value stream은 Stage의 컨테이너 객체입니다. DevOps 라이프사이클의 다양한 측면에 집중하기 위해 그룹당 여러 value stream을 가질 수 있습니다.

Value stream Stage#

Stage는 이름과 같은 추가 메타데이터가 있는 이벤트 쌍(시작 및 종료 이벤트)을 나타냅니다. 재정렬하고 숨길 수 있는 기본 제공 기본 Stage로 value stream 분석을 사용할 수 있습니다. 특정 개발 워크플로에 맞는 사용자 정의 Stage를 만들고 추가할 수도 있습니다.

Value stream Stage 이벤트#

히스토리
  • 머지 리퀘스트 첫 번째 리뷰어 할당 이벤트가 GitLab 17.2에서 도입됨. GitLab 17.2 이전에 생성되거나 업데이트된 머지 리퀘스트의 리뷰어 할당 이벤트는 보고에 사용할 수 없습니다.

이벤트는 Stage가 시작하고 종료되는 시점을 정의하는 기본 요소입니다. 각 이벤트에는 시작 시간과 종료 시간이 있습니다:

  • 시작 이벤트 시간은 Stage에서 작업이 시작되는 시점을 표시합니다 (예: 이슈가 생성될 때).
  • 종료 이벤트 시간은 Stage에서 작업이 완료되는 시점을 표시합니다 (예: 이슈가 닫힐 때).

GitLab은 이 공식을 사용하여 시작 및 종료 이벤트 시간을 기반으로 Stage 기간을 계산합니다: Stage 기간 = 종료 이벤트 시간 - 시작 이벤트 시간

Value stream 분석은 다음 이벤트를 지원합니다:

  • Issue closed
  • Issue created
  • Issue first added to a board
  • Issue first added to iteration
  • Issue first assigned
  • Issue first associated with a milestone
  • Issue first mentioned in a commit
  • Issue label added
  • Issue label removed
  • Merge request closed
  • Merge request created
  • Merge request first assigned
  • Merge request first committed
  • Merge request first deployed to production
  • Merge request label added
  • Merge request label removed
  • Merge request last approved
  • Merge request last build finished
  • Merge request last build started
  • Merge request merged
  • Merge request reviewer first assigned

Stage 이벤트에 대한 아이디어나 피드백은 이슈 520962에서 공유할 수 있습니다.

데이터 집계#

히스토리
  • 종료 날짜별 필터링 활성화가 GitLab 15.0에서 추가

Value stream 분석은 백엔드 프로세스를 사용하여 Stage 수준 데이터를 수집하고 집계합니다. 이를 통해 많은 수의 이슈와 머지 리퀘스트를 가진 대규모 그룹을 위해 확장될 수 있습니다. 이 프로세스로 인해 작업이 수행된 시점(예: 이슈 닫기)과 데이터가 value stream 분석 페이지에 표시되는 시점 사이에 약간의 지연이 있을 수 있습니다.

데이터를 처리하고 결과를 표시하는 데 최대 10분이 걸릴 수 있습니다. 다음의 경우 데이터 수집에 10분 이상이 걸릴 수 있습니다:

  • Value stream 분석을 처음 보고 있고 아직 value stream을 생성하지 않은 경우.
  • 그룹 계층이 재배치된 경우.
  • 이슈와 머지 리퀘스트에 대한 일괄 업데이트가 있는 경우.

데이터가 가장 최근에 업데이트된 시점을 보려면 Edit 옆의 오른쪽 모서리에서 Last updated 배지를 호버합니다.

Stage 측정#

Value stream 분석은 시작 이벤트부터 종료 이벤트까지 각 Stage를 측정합니다. 종료 이벤트에 도달한 항목만 Stage 시간 계산에 포함됩니다.

기본적으로 차단된 이슈는 라이프사이클 개요에 포함되지 않습니다. 그러나 사용자 정의 레이블(예: workflow::blocked)을 사용하여 추적할 수 있습니다.

미리 정의된 이벤트를 기반으로 value stream 분석에서 Stage를 사용자 정의할 수 있습니다. 구성을 돕기 위해 GitLab은 템플릿으로 사용할 수 있는 미리 정의된 Stage 목록을 제공합니다. 예를 들어 이슈에 레이블을 추가할 때 시작하고 다른 레이블을 추가할 때 종료하는 Stage를 정의할 수 있습니다.

다음 표는 value stream 분석의 미리 정의된 Stage 개요를 제공합니다.

Stage 측정 방법
Issue 이슈를 생성하는 것과 레이블을 지정하거나 마일스톤에 추가하는 등 해결 조치를 취하는 것 사이의 중앙값 시간, 어느 것이 먼저 오든. 레이블에 이슈 보드 목록이 이미 생성된 경우에만 추적됩니다.
Plan 이전 Stage를 위해 취한 조치와 브랜치에 첫 번째 커밋을 푸시하는 것 사이의 중앙값 시간. 브랜치의 첫 번째 커밋이 PlanCode 사이의 분리를 트리거합니다. 브랜치의 커밋 중 하나 이상에는 관련 이슈 번호가 포함되어야 합니다 (예: #42). 브랜치의 커밋 중 어느 것도 관련 이슈 번호를 언급하지 않으면 Stage 측정 시간에서 고려되지 않습니다.
Code 첫 번째 커밋 푸시(이전 Stage)와 해당 커밋과 관련된 머지 리퀘스트(MR) 생성 사이의 중앙값 시간. 프로세스를 추적 상태로 유지하는 핵심은 머지 리퀘스트의 설명에 이슈 닫기 패턴을 포함시키는 것입니다. 예를 들어 Closes #xxx(여기서 xxx는 이 머지 리퀘스트와 관련된 이슈 번호). 닫기 패턴이 없으면 계산은 머지 리퀘스트의 첫 번째 커밋 생성 시간을 시작 시간으로 사용합니다.
Test 해당 프로젝트에 대한 전체 파이프라인을 실행하는 중앙값 시간. GitLab CI/CD가 해당 머지 리퀘스트에 푸시된 커밋에 대한 모든 job을 실행하는 데 걸리는 시간과 관련됩니다. 기본적으로 모든 파이프라인의 시작->완료 시간입니다.
Review 닫기 이슈 패턴이 있는 머지 리퀘스트를 생성부터 머지까지 검토하는 데 걸리는 중앙값 시간.
Staging 닫기 이슈 패턴이 있는 머지 리퀘스트를 머지하는 것부터 프로덕션 환경에 대한 첫 번째 배포까지의 중앙값 시간. 프로덕션 환경이 없으면 추적되지 않습니다.
Note

Value stream 분석은 타임스탬프 데이터로 작동하며 Stage의 최종 시작 및 중지 이벤트만 집계합니다. 여러 번 Stage 사이를 앞뒤로 이동하는 항목의 경우 Stage 시간은 최종 이벤트의 타임스탬프에서만 계산됩니다.

예시 워크플로#

이 예시는 하루에 7개 Stage를 모두 통과하는 워크플로를 보여줍니다.

Stage에 시작 시간과 중지 시간이 포함되지 않은 경우 해당 데이터는 중앙값 시간에 포함되지 않습니다. 이 예시에서는 마일스톤이 생성되고 테스트 및 환경 설정을 위한 CI/CD가 구성되었습니다.

  • 09:00: 이슈 생성. Issue Stage 시작.
  • 11:00: 이슈를 마일스톤(또는 백로그)에 추가하고, 이슈 작업을 시작하고, 로컬에서 브랜치 생성. Issue Stage 종료 및 Plan Stage 시작.
  • 12:00: 첫 번째 커밋 수행.
  • 12:30: 이슈 번호를 언급하는 브랜치에 두 번째 커밋 수행. Plan Stage 종료 및 Code Stage 시작.
  • 14:00: 브랜치 푸시 및 이슈 닫기 패턴이 포함된 머지 리퀘스트 생성. Code Stage 종료 및 TestReview Stage 시작.
  • GitLab CI/CD가 .gitlab-ci.yml 파일에 정의된 스크립트를 실행하는 데 5분 걸림.
  • 19:00: 머지 리퀘스트 머지. Review Stage 종료 및 Staging Stage 시작.
  • 19:30: production 환경에 대한 배포 완료. Staging 종료.

Value stream 분석은 각 Stage에 대해 다음 시간을 기록합니다:

  • Issue: 09:00부터 11:00까지: 2시간
  • Plan: 11:00부터 12:00까지: 1시간
  • Code: 12:00부터 14:00까지: 2시간
  • Test: 5분
  • Review: 14:00부터 19:00까지: 5시간
  • Staging: 19:00부터 19:30까지: 30분

이 예시와 관련된 다음 관찰 사항을 염두에 두세요:

  • 이 예시는 첫 번째 커밋이 이슈 번호를 언급하지 않아도 된다는 것을 보여줍니다. 작업 중인 브랜치의 이후 커밋에서 이를 수행할 수 있습니다.
  • Test Stage는 전체 사이클 시간 계산에 사용됩니다. 모든 MR은 테스트되어야 하기 때문에 Review 프로세스에 포함됩니다.
  • 이 예시는 7개 Stage 중 하나의 사이클만 보여줍니다. Value stream 분석 대시보드는 여러 사이클의 중앙값 시간을 보여줍니다.

누적 레이블 이벤트 기간#

히스토리
  • GitLab 16.9에서 enable_vsa_cumulative_label_duration_calculationvsa_duration_from_db라는 플래그를 사용하여 도입됨. 기본적으로 비활성화.
  • GitLab 16.10에서 GitLab.com 및 GitLab Self-Managed에서 활성화. 기능 플래그 vsa_duration_from_db 제거됨.
  • 기능 플래그 enable_vsa_cumulative_label_duration_calculation이 GitLab 17.0에서 제거됨.

이 기능을 사용하면 value stream 분석이 레이블 기반 Stage의 반복 이벤트 기간을 측정합니다. Stage의 시작 및 종료 이벤트 모두에 대한 레이블 제거 또는 추가 이벤트를 구성해야 합니다.

예를 들어 Stage가 in progress 레이블이 추가되고 제거되는 시기를 추적하는 경우, 다음 시간이 있습니다:

  • 9:00: 레이블 추가.
  • 10:00: 레이블 제거.
  • 12:00: 레이블 추가.
  • 14:00: 레이블 제거.

원래 계산 방법으로는 기간이 5시간입니다 (9:00부터 14:00까지). 누적 레이블 이벤트 기간 계산이 활성화되면 기간은 3시간입니다 (9:00부터 10:00까지 및 12:00부터 14:00까지).

Note

GitLab 버전을 16.10(또는 더 높은 버전)으로 업그레이드하면 기존 레이블 기반 value stream 분석 Stage가 백그라운드 집계 프로세스를 사용하여 자동으로 재집계됩니다.

업그레이드 후 데이터 재집계#

대규모 인스턴스에서 GitLab 버전을 업그레이드할 때, 특히 여러 마이너 버전을 건너뛰면 백그라운드 집계 프로세스가 더 오래 지속될 수 있습니다. 이 지연으로 인해 Value Stream Analytics 페이지의 데이터가 오래될 수 있습니다. 집계 프로세스를 가속화하고 오래된 데이터를 방지하려면 rails 콘솔에서 특정 그룹에 대한 동기 집계 스니펫을 호출할 수 있습니다:

group = Group.find(-1) # put your group id here
group_to_aggregate = group.root_ancestor

loop do
  cursor = {}
  context = Analytics::CycleAnalytics::AggregationContext.new(cursor: cursor)
  service_response = Analytics::CycleAnalytics::DataLoaderService.new(group: group_to_aggregate, model: Issue, context: context).execute

  if service_response.success? && service_response.payload[:reason] == :limit_reached
    cursor = service_response.payload[:context].cursor
  elsif service_response.success?
    puts "finished"
    break
  else
    puts "failed"
    break
  end
end

loop do
  cursor = {}
  context = Analytics::CycleAnalytics::AggregationContext.new(cursor: cursor)
  service_response = Analytics::CycleAnalytics::DataLoaderService.new(group: group_to_aggregate, model: MergeRequest, context: context).execute

  if service_response.success? && service_response.payload[:reason] == :limit_reached
    cursor = service_response.payload[:context].cursor
  elsif service_response.success?
    puts "finished"
    break
  else
    puts "failed"
    break
  end
end

프로덕션 환경#

Value stream 분석은 다음 패턴 중 하나와 일치하는 이름의 프로젝트 환경을 찾아 프로덕션 환경을 식별합니다:

  • prod 또는 prod/*
  • production 또는 production/*

이 패턴은 대소문자를 구분하지 않습니다.

GitLab CI/CD 구성에서 프로젝트 환경의 이름을 변경할 수 있습니다.

Value stream 분석 보기#

히스토리
  • 미리 정의된 날짜 범위 드롭다운 목록이 GitLab 16.5에서 vsa_predefined_date_ranges라는 플래그를 사용하여 도입됨. 기본적으로 비활성화.
  • 미리 정의된 날짜 범위 드롭다운 목록이 GitLab 16.7에서 GitLab Self-Managed 및 GitLab.com에서 활성화됨.
  • 미리 정의된 날짜 범위 드롭다운 목록이 GitLab 16.9에서 일반 사용 가능하게 됨. 기능 플래그 vsa_predefined_date_ranges 제거됨.

사전 요구 사항:

  • Reporter, Developer, Maintainer 또는 Owner 권한이 있어야 합니다.
  • 사용자 정의 value stream을 생성해야 합니다. Value stream 분석은 그룹 또는 프로젝트에 대해 생성된 사용자 정의 value stream만 표시합니다.

그룹 또는 프로젝트의 value stream 분석을 보려면:

  1. 상단 표시줄에서 Search or go to를 선택하고 프로젝트 또는 그룹을 찾습니다.
  2. 왼쪽 사이드바에서 Analyze > Value stream analytics를 선택합니다.
  3. 특정 Stage의 메트릭을 보려면 Filter results 텍스트 상자 아래의 Stage를 선택합니다.
  4. 선택 사항. 결과 필터링:
    1. Filter results 텍스트 상자를 선택합니다.

    2. 매개변수를 선택합니다.

    3. 결과를 좁히기 위한 값을 선택하거나 텍스트를 입력합니다.

    4. 특정 날짜 범위의 메트릭을 보려면 드롭다운 목록에서 미리 정의된 날짜 범위 또는 Custom 옵션을 선택합니다. Custom 옵션이 선택된 경우:

      • From 필드에서 시작 날짜를 선택합니다.
      • To 필드에서 종료 날짜를 선택합니다.

      차트와 목록은 날짜 범위 동안 생성된 워크플로 항목을 표시합니다.

  5. 선택 사항. 오름차순 또는 내림차순으로 결과 정렬:
    • 가장 최근 또는 가장 오래된 워크플로 항목으로 정렬하려면 Last event 헤더를 선택합니다.
    • 각 Stage에서 가장 많거나 가장 적은 시간이 소요된 것으로 정렬하려면 Duration 헤더를 선택합니다.

워크플로 항목 테이블 헤더 옆의 배지는 선택한 Stage 동안 완료된 워크플로 항목 수를 표시합니다.

테이블은 선택한 Stage에 대한 관련 워크플로 항목 목록을 표시합니다. 선택한 Stage에 따라 다음일 수 있습니다:

  • 이슈
  • 머지 리퀘스트
Note

각 미리 정의된 날짜 범위의 종료 날짜는 현재 날입니다. 이는 선택한 일수에 포함됩니다. 예를 들어 Last 30 days의 시작 날짜는 총 30일 동안 현재 날로부터 29일 전입니다.

데이터 필터#

특정 기준과 일치하는 데이터를 보기 위해 value stream 분석을 필터링할 수 있습니다. 다음 필터가 지원됩니다:

  • 날짜 범위
  • 프로젝트
  • 담당자
  • 작성자
  • 마일스톤
  • 레이블

Value stream 분석 메트릭#

Value stream 분석의 Overview 페이지는 프로젝트 및 그룹에 대한 DevSecOps 라이프사이클 성능의 주요 메트릭을 표시합니다.

라이프사이클 메트릭#

Value stream 분석에는 다음 라이프사이클 메트릭이 포함됩니다:

  • Lead time: 이슈가 생성된 시점부터 닫힌 시점까지의 중앙값 시간.
  • Cycle time: 이슈가 머지 리퀘스트의 커밋 메시지에 처음 참조된 시점부터 해당 참조된 이슈가 닫힌 시점까지의 중앙값 시간. 커밋 메시지에 이슈 번호 앞에 #을 포함해야 합니다 (예: #123). 그렇지 않으면 데이터가 표시되지 않습니다. 사이클 시간은 일반적으로 머지 리퀘스트가 첫 번째 커밋 후에 생성되기 때문에 리드 타임보다 짧습니다.
  • New issues: 생성된 새 이슈 수.
  • Deploys: 프로덕션에 대한 총 배포 수.

DORA 메트릭#

히스토리
  • GitLab 15.0에서 서비스 복구 시간 타일이 도입됨.
  • GitLab 15.0에서 변경 실패율 타일이 도입됨.

Value stream 분석에는 다음 DORA 메트릭이 포함됩니다:

  • 배포 빈도
  • 변경 리드 타임
  • 서비스 복구 시간
  • 변경 실패율

DORA 메트릭은 DORA API의 데이터를 기반으로 계산됩니다.

GitLab Premium 또는 Ultimate 구독이 있는 경우:

  • 성공한 배포 수는 DORA 데이터로 계산됩니다.
  • 데이터는 환경 및 환경 티어에 따라 필터링됩니다.

라이프사이클 및 DORA 메트릭 보기#

사전 요구 사항:

라이프사이클 메트릭을 보려면:

  1. 상단 표시줄에서 Search or go to를 선택하고 프로젝트 또는 그룹을 찾습니다.
  2. 왼쪽 사이드바에서 Analyze > Value stream analytics를 선택합니다. 라이프사이클 메트릭은 Filter results 텍스트 상자 아래에 표시됩니다.
  3. 선택 사항. 결과 필터링:
    1. Filter results 텍스트 상자를 선택합니다. 선택한 필터에 따라 대시보드가 자동으로 라이프사이클 메트릭을 집계하고 value stream 상태를 표시합니다.
    2. 매개변수를 선택합니다.
    3. 결과를 좁히기 위한 값을 선택하거나 텍스트를 입력합니다.
    4. 날짜 범위를 조정하려면:
      • From 필드에서 시작 날짜를 선택합니다.
      • To 필드에서 종료 날짜를 선택합니다.

Value Streams DashboardDORA 메트릭을 보려면:

  1. 상단 표시줄에서 Search or go to를 선택하고 프로젝트 또는 그룹을 찾습니다.
  2. 왼쪽 사이드바에서 Analyze > Value stream analytics를 선택합니다.
  3. Filter results 텍스트 상자 아래의 Lifecycle metrics 행에서 Value Streams Dashboard / DORA를 선택합니다.
  4. 선택 사항. 새 페이지를 열려면 그룹 URL에 이 경로 /analytics/dashboards/value_streams_dashboard를 추가합니다 (예: https://gitlab.com/groups/gitlab-org/-/analytics/dashboards/value_streams_dashboard).

각 개발 Stage의 메트릭 보기#

Value stream 분석은 각 개발 Stage에서 이슈 또는 머지 리퀘스트가 소요하는 중앙값 시간을 표시합니다.

그룹별로 각 Stage에서 소요된 중앙값 시간을 보려면:

  1. 상단 표시줄에서 Search or go to를 선택하고 프로젝트 또는 그룹을 찾습니다.
  2. 왼쪽 사이드바에서 Analyze > Value stream analytics를 선택합니다.
  3. 선택 사항. 결과 필터링:
    1. Filter results 텍스트 상자를 선택합니다.
    2. 매개변수를 선택합니다.
    3. 결과를 좁히기 위한 값을 선택하거나 텍스트를 입력합니다.
    4. 날짜 범위를 조정하려면:
      • From 필드에서 시작 날짜를 선택합니다.
      • To 필드에서 종료 날짜를 선택합니다.
  4. 각 Stage의 메트릭을 보려면 Filter results 텍스트 상자 위의 Stage를 호버합니다.
Note

날짜 범위 선택기는 이벤트 시간별로 항목을 필터링합니다. 이벤트 시간은 지정된 항목에 대해 선택한 Stage가 완료된 시점입니다.

유형별 작업 보기#

Tasks by type 차트는 그룹에 대해 하루에 완료된 작업(닫힌 이슈 및 머지된 머지 리퀘스트) 수를 누적으로 표시합니다.

차트는 전역 페이지 필터를 사용하여 선택한 그룹 및 시간 프레임을 기반으로 데이터를 표시합니다.

유형별 작업을 보려면:

  1. 상단 표시줄에서 Search or go to를 선택하고 그룹을 찾습니다.
  2. 왼쪽 사이드바에서 Analyze > Value stream analytics를 선택합니다.
  3. Filter results 텍스트 상자 아래에서 Overview를 선택합니다. Tasks by type 차트가 Total time 차트 아래에 표시됩니다.
  4. 선택 사항. 유형별로 작업을 필터링하려면 Settings (⚙️)를 선택한 다음 Issues 또는 Merge Requests를 선택합니다.
  5. 선택 사항. 레이블별로 작업을 필터링하려면 Settings (⚙️)를 선택한 다음 하나 이상의 레이블을 선택합니다. 기본적으로 상위 그룹 레이블(최대 10개)이 선택됩니다. 최대 15개의 레이블을 선택할 수 있습니다.

Value stream 생성#

히스토리
  • New value stream이 GitLab 16.10에서 vsa_standalone_settings_page라는 플래그를 사용하여 대화 상자에서 페이지로 변경됨. 기본적으로 비활성화.
  • GitLab 17.7에서 일반 사용 가능하게 됨. 기능 플래그 vsa_standalone_settings_page 제거됨.

기본 Stage로#

기본 Stage로 value stream을 생성하려면:

  1. 상단 표시줄에서 Search or go to를 선택하고 프로젝트 또는 그룹을 찾습니다.
  2. 왼쪽 사이드바에서 Analyze > Value Stream analytics를 선택합니다.
  3. New Value Stream을 선택합니다.
  4. Value stream 이름을 입력합니다.
  5. Create from default template을 선택합니다.
  6. 기본 Stage를 사용자 정의합니다:
    • Stage 순서를 변경하려면 위쪽 또는 아래쪽 화살표를 선택합니다.
    • Stage를 숨기려면 Hide ([eye-slash])를 선택합니다.
  7. 사용자 정의 Stage를 추가하려면 Add a stage를 선택합니다.
    • Stage 이름을 입력합니다.
    • Start eventStop event를 선택합니다.
  8. New value stream을 선택합니다.
Note

최근에 GitLab Premium으로 업그레이드한 경우 데이터를 수집하고 표시하는 데 최대 30분이 걸릴 수 있습니다.

사용자 정의 Stage로#

사용자 정의 Stage로 value stream을 생성하려면:

  1. 상단 표시줄에서 Search or go to를 선택하고 프로젝트 또는 그룹을 찾습니다.
  2. 왼쪽 사이드바에서 Analyze > Value Stream analytics를 선택합니다.
  3. New value stream을 선택합니다.
  4. 각 Stage에 대해:
    • Stage 이름을 입력합니다.
    • Start eventStop event를 선택합니다.
  5. 다른 Stage를 추가하려면 Add a stage를 선택합니다.
  6. Stage 순서를 변경하려면 위쪽 또는 아래쪽 화살표를 선택합니다.
  7. New value stream을 선택합니다.

비디오 설명은 Value Stream Analytics로 머지 리퀘스트 리뷰 프로세스 최적화를 참조하세요.

사용자 정의 Value stream의 레이블 기반 Stage#

복잡한 워크플로를 측정하기 위해 범위가 지정된 레이블을 사용할 수 있습니다. 예를 들어 스테이징 환경에서 프로덕션까지의 배포 시간을 측정하기 위해 다음 레이블을 사용할 수 있습니다:

  • 코드가 스테이징에 배포될 때 머지 리퀘스트에 workflow::staging 레이블이 추가됩니다.
  • 코드가 프로덕션에 배포될 때 머지 리퀘스트에 workflow::production 레이블이 추가됩니다.

Label-based value stream analytics stage

웹훅을 사용한 자동 데이터 레이블 지정#

GitLab 웹훅 이벤트를 사용하여 레이블을 자동으로 추가할 수 있습니다. 이를 통해 특정 이벤트가 발생할 때 머지 리퀘스트 또는 이슈에 레이블이 적용됩니다. 그런 다음 레이블 기반 Stage를 추가하여 워크플로를 추적할 수 있습니다. 구현에 대한 자세한 내용은 블로그 게시물 GitLab Labels 자동으로 적용하기를 참조하세요.

예시 구성#

Example configuration

이전 예시에서 Test Group(최상위 네임스페이스)에서 서로 다른 개발 워크플로를 사용하는 두 팀을 위해 두 개의 독립적인 value stream이 설정되었습니다.

첫 번째 value stream은 Stage 정의를 위한 표준 타임스탬프 기반 이벤트를 사용합니다. 두 번째 value stream은 레이블 이벤트를 사용합니다.

Value stream 편집#

히스토리
  • Edit value stream이 GitLab 16.10에서 vsa_standalone_settings_page라는 플래그를 사용하여 대화 상자에서 페이지로 변경됨. 기본적으로 비활성화.
  • GitLab 17.7에서 일반 사용 가능하게 됨. 기능 플래그 vsa_standalone_settings_page 제거됨.

Value stream을 생성한 후 목적에 맞게 사용자 정의할 수 있습니다. Value stream을 편집하려면:

  1. 상단 표시줄에서 Search or go to를 선택하고 프로젝트 또는 그룹을 찾습니다.
  2. 왼쪽 사이드바에서 Analyze > Value stream analytics를 선택합니다.
  3. Value stream 드롭다운 목록에서 편집하려는 value stream을 선택합니다.
  4. Value stream 드롭다운 목록 옆에서 Edit를 선택합니다.
  5. 선택 사항:
    • Value stream 이름 변경.
    • 기본 Stage 숨기거나 재정렬.
    • 기존 사용자 정의 Stage 제거.
    • 새 Stage를 추가하려면 Add a stage를 선택합니다.
    • Stage의 시작 및 종료 이벤트 선택.
  6. 선택 사항. 수정 사항을 실행 취소하려면 Restore value stream defaults를 선택합니다.
  7. Save Value Stream을 선택합니다.

Value stream 삭제#

사용자 정의 value stream을 삭제하려면:

  1. 상단 표시줄에서 Search or go to를 선택하고 프로젝트 또는 그룹을 찾습니다.
  2. 왼쪽 사이드바에서 Analyze > Value stream analytics를 선택합니다.
  3. Value stream 드롭다운 목록에서 삭제하려는 value stream을 선택하고 **Delete (value stream 이름)**을 선택합니다.
  4. 확인하려면 Delete를 선택합니다.

사이클 완료에 걸리는 일수 보기#

Total time chart는 개발 사이클이 완료되는 데 걸리는 평균 일수를 표시합니다. 차트는 마지막 500개의 워크플로 항목에 대한 데이터를 표시합니다.

  1. 상단 표시줄에서 Search or go to를 선택하고 프로젝트 또는 그룹을 찾습니다.
  2. 왼쪽 사이드바에서 Analyze > Value stream analytics를 선택합니다.
  3. Filter results 상자 위에서 Stage를 선택합니다:
    • 모든 Stage의 사이클 시간 요약을 보려면 Overview를 선택합니다.
    • 특정 Stage의 사이클 시간을 보려면 Stage를 선택합니다.
  4. 선택 사항. 결과 필터링:
    1. Filter results 텍스트 상자를 선택합니다.
    2. 매개변수를 선택합니다.
    3. 결과를 좁히기 위한 값을 선택하거나 텍스트를 입력합니다.
    4. 날짜 범위를 조정하려면:
      • From 필드에서 시작 날짜를 선택합니다.
      • To 필드에서 종료 날짜를 선택합니다.

액세스 권한#

Value stream 분석의 액세스 권한은 프로젝트 유형에 따라 다릅니다.

프로젝트 유형 권한
Public 누구나 액세스 가능.
Internal 인증된 모든 사용자가 액세스 가능.
Private Guest, Planner, Reporter, Developer, Maintainer 또는 Owner 권한이 있는 사용자가 액세스 가능.

Value Stream Analytics GraphQL API#

히스토리
  • GraphQL을 통한 Stage 메트릭 로딩이 GitLab 17.0에서 도입됨.

VSA GraphQL API를 사용하면 구성된 value stream 및 value stream Stage에서 메트릭을 요청할 수 있습니다. VSA 데이터를 외부 시스템이나 보고서로 내보내려는 경우 유용합니다.

다음 메트릭을 사용할 수 있습니다:

  • Stage에서 완료된 항목 수. 카운트는 최대 10,000개 항목으로 제한됩니다.
  • Stage에서 완료된 항목의 중앙값 기간.
  • Stage에서 완료된 항목의 평균 기간.

메트릭 요청#

사전 요구 사항:

  • Reporter, Developer, Maintainer 또는 Owner 권한이 있어야 합니다.

먼저 보고에 사용할 value stream을 결정해야 합니다.

그룹에 대해 구성된 value stream을 요청하려면 실행하세요:

group(fullPath: "your-group-path") {
  valueStreams {
    nodes {
      id
      name
    }
  }
}

마찬가지로 프로젝트에 대한 메트릭을 요청하려면 실행하세요:

project(fullPath: "your-project-path") {
  valueStreams {
    nodes {
      id
      name
    }
  }
}

Value stream Stage에 대한 메트릭을 요청하려면 실행하세요:

group(fullPath: "your-group-path") {
  valueStreams(id: "your-value-stream-id") {
    nodes {
      stages {
        id
        name
      }
    }
  }
}

데이터를 어떻게 사용할지에 따라 특정 Stage 또는 value stream의 모든 Stage에 대한 메트릭을 요청할 수 있습니다.

Note

모든 Stage에 대한 메트릭을 요청하면 일부 설치에서는 너무 느릴 수 있습니다. 권장되는 방법은 Stage별로 메트릭을 요청하는 것입니다.

Stage에 대한 메트릭 요청:

group(fullPath: "your-group-path") {
  valueStreams(id: "your-value-stream-id") {
    nodes {
      stages(id: "your-stage-id") {
        id
        name
        metrics(timeframe: { start: "2024-03-01", end: "2024-03-31" }) {
          average {
            value
            unit
          }
          median {
            value
            unit
          }
          count {
            value
            unit
          }
        }
      }
    }
  }
}
Note

항상 주어진 시간 프레임으로 메트릭을 요청해야 합니다. 지원되는 가장 긴 시간 프레임은 180일입니다.

metrics 노드는 추가 필터링 옵션을 지원합니다:

  • 담당자 사용자 이름
  • 작성자 사용자 이름
  • 레이블 이름
  • 마일스톤 제목

필터를 포함한 예시 요청:

group(fullPath: "your-group-path") {
  valueStreams(id: "your-value-stream-id") {
    nodes {
      stages(id: "your-stage-id") {
        id
        name
        metrics(
          labelNames: ["backend"],
          milestoneTitle: "17.0",
          timeframe: { start: "2024-03-01", end: "2024-03-31" }
        ) {
          average {
            value
            unit
          }
          median {
            value
            unit
          }
          count {
            value
            unit
          }
        }
      }
    }
  }
}

모범 사례#

  • 현재 상태의 정확한 보기를 얻으려면 시간 프레임이 종료되는 시점에 가능한 한 가깝게 메트릭을 요청합니다.
  • 정기적인 보고를 위해 스크립트를 만들고 예약된 파이프라인 기능을 사용하여 적시에 데이터를 내보낼 수 있습니다.
  • API를 호출하면 데이터베이스에서 현재 데이터를 가져옵니다. 시간이 지남에 따라 동일한 메트릭이 데이터베이스의 기본 데이터 변경으로 인해 변경될 수 있습니다. 예를 들어 그룹에서 프로젝트를 이동하거나 제거하면 그룹 수준 메트릭에 영향을 줄 수 있습니다.
  • 이전 기간의 메트릭을 다시 요청하고 이전에 수집된 메트릭과 비교하면 데이터의 왜곡을 보여줄 수 있어 변화하는 트렌드를 발견하고 설명하는 데 도움이 됩니다.

기능 가용성#

Value stream 분석은 FOSS 및 라이선스 버전의 프로젝트 및 그룹 수준에서 다양한 기능을 제공합니다.

  • GitLab Free에서 value stream 분석은 데이터를 집계하지 않습니다. 날짜 범위 필터가 이슈 및 머지 리퀘스트의 생성 날짜에 적용되는 데이터베이스를 직접 쿼리합니다. 미리 정의된 기본 Stage로 value stream 분석을 볼 수 있습니다.
  • GitLab Premium에서 value stream 분석은 데이터를 집계하고 종료 이벤트에 날짜 범위 필터를 적용합니다. Value stream을 생성, 편집 및 삭제할 수도 있습니다.
기능 그룹 수준 (라이선스) 프로젝트 수준 (라이선스) 프로젝트 수준 (FOSS)
사용자 정의 value stream 생성 아니오, 기본 Stage가 있는 하나의 value stream(기본)만 있음
사용자 정의 Stage 생성 아니오
필터링 (예: 작성자, 레이블, 마일스톤별)
Stage 시간 차트 아니오
총 시간 차트 아니오
유형별 작업 차트 아니오 아니오
DORA 메트릭 아니오
사이클 시간 및 리드 타임 요약 (라이프사이클 메트릭) 아니오
새 이슈, 커밋 및 배포 (라이프사이클 메트릭) 예, 커밋 제외
집계된 백엔드 사용 아니오
날짜 필터 동작 날짜 범위 내에 완료된 항목 필터링 생성 날짜별로 항목 필터링. 생성 날짜별로 항목 필터링.
권한 최소 reporter 최소 reporter 공개 가능

트러블슈팅#

Sidekiq cronjob:analytics_cycle_analytics에 의한 CPU 100% 사용#

Value stream 분석 백그라운드 job이 CPU 리소스를 독점하여 성능에 심각한 영향을 미칠 수 있습니다.

이 상황에서 복구하려면:

  1. Rails 콘솔에서 모든 프로젝트에 대해 기능을 비활성화하고 기존 job을 제거합니다:

    Project.find_each do |p|
      p.analytics_access_level='disabled';
      p.save!
    end
    
    Analytics::CycleAnalytics::GroupStage.delete_all
    Analytics::CycleAnalytics::Aggregation.delete_all
    
  2. 예를 들어 단일 feature_category=value_stream_management와 여러 feature_category!=value_stream_management 항목으로 Sidekiq 라우팅을 구성합니다. Enterprise Edition 목록에서 다른 관련 큐 메타데이터를 찾아보세요.

  3. 프로젝트 하나씩 value stream 분석을 활성화합니다. 성능 요구 사항에 따라 Sidekiq 라우팅을 추가로 조정해야 할 수 있습니다.

Value Stream 분석

Tier: Free, Premium, Ultimate
Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated
원문 보기
요약

Value stream 분석은 소프트웨어 개발 프로세스의 모든 단계 기간을 계산합니다. Value stream 분석을 사용하여 다음을 식별합니다: Value stream 분석은 비즈니스에 도움을 줍니다: 클릭 가능한 데모는 Value Stream Management 제품 투어를 참조하세요.

Value stream 분석은 소프트웨어 개발 프로세스의 모든 단계 기간을 계산합니다. 머지 리퀘스트 또는 이슈 이벤트를 추적하여 아이디어에서 프로덕션까지 얼마나 걸리는지 측정할 수 있습니다.

Value stream 분석을 사용하여 다음을 식별합니다:

  • 아이디어에서 프로덕션까지 걸리는 시간.
  • 특정 프로젝트의 속도.
  • 개발 프로세스의 병목 현상.
  • 오래 실행되는 이슈 또는 머지 리퀘스트.
  • 소프트웨어 개발 라이프사이클을 느리게 만드는 요인.

Value stream 분석은 비즈니스에 도움을 줍니다:

  • 종단간 DevSecOps 워크스트림 시각화.
  • 비효율성 식별 및 해결.
  • 더 많은 가치를 더 빠르게 제공하기 위한 워크스트림 최적화 (예: 머지 리퀘스트 리뷰 시간 단축).

클릭 가능한 데모는 Value Stream Management 제품 투어를 참조하세요.

Value stream 분석은 계층적 구조를 가집니다:

  • Value stream은 value stream Stage 목록을 포함합니다.
  • 각 value stream Stage 목록은 하나 이상의 Stage를 포함합니다.
  • 각 Stage는 두 개의 이벤트로 정의됩니다: 시작과 종료.

Value stream#

Value stream은 고객에게 가치를 전달하는 전체 업무 프로세스입니다. Value stream은 Stage의 컨테이너 객체입니다. DevOps 라이프사이클의 다양한 측면에 집중하기 위해 그룹당 여러 value stream을 가질 수 있습니다.

Value stream Stage#

Stage는 이름과 같은 추가 메타데이터가 있는 이벤트 쌍(시작 및 종료 이벤트)을 나타냅니다. 재정렬하고 숨길 수 있는 기본 제공 기본 Stage로 value stream 분석을 사용할 수 있습니다. 특정 개발 워크플로에 맞는 사용자 정의 Stage를 만들고 추가할 수도 있습니다.

Value stream Stage 이벤트#

히스토리
  • 머지 리퀘스트 첫 번째 리뷰어 할당 이벤트가 GitLab 17.2에서 도입됨. GitLab 17.2 이전에 생성되거나 업데이트된 머지 리퀘스트의 리뷰어 할당 이벤트는 보고에 사용할 수 없습니다.

이벤트는 Stage가 시작하고 종료되는 시점을 정의하는 기본 요소입니다. 각 이벤트에는 시작 시간과 종료 시간이 있습니다:

  • 시작 이벤트 시간은 Stage에서 작업이 시작되는 시점을 표시합니다 (예: 이슈가 생성될 때).
  • 종료 이벤트 시간은 Stage에서 작업이 완료되는 시점을 표시합니다 (예: 이슈가 닫힐 때).

GitLab은 이 공식을 사용하여 시작 및 종료 이벤트 시간을 기반으로 Stage 기간을 계산합니다: Stage 기간 = 종료 이벤트 시간 - 시작 이벤트 시간

Value stream 분석은 다음 이벤트를 지원합니다:

  • Issue closed
  • Issue created
  • Issue first added to a board
  • Issue first added to iteration
  • Issue first assigned
  • Issue first associated with a milestone
  • Issue first mentioned in a commit
  • Issue label added
  • Issue label removed
  • Merge request closed
  • Merge request created
  • Merge request first assigned
  • Merge request first committed
  • Merge request first deployed to production
  • Merge request label added
  • Merge request label removed
  • Merge request last approved
  • Merge request last build finished
  • Merge request last build started
  • Merge request merged
  • Merge request reviewer first assigned

Stage 이벤트에 대한 아이디어나 피드백은 이슈 520962에서 공유할 수 있습니다.

데이터 집계#

히스토리
  • 종료 날짜별 필터링 활성화가 GitLab 15.0에서 추가

Value stream 분석은 백엔드 프로세스를 사용하여 Stage 수준 데이터를 수집하고 집계합니다. 이를 통해 많은 수의 이슈와 머지 리퀘스트를 가진 대규모 그룹을 위해 확장될 수 있습니다. 이 프로세스로 인해 작업이 수행된 시점(예: 이슈 닫기)과 데이터가 value stream 분석 페이지에 표시되는 시점 사이에 약간의 지연이 있을 수 있습니다.

데이터를 처리하고 결과를 표시하는 데 최대 10분이 걸릴 수 있습니다. 다음의 경우 데이터 수집에 10분 이상이 걸릴 수 있습니다:

  • Value stream 분석을 처음 보고 있고 아직 value stream을 생성하지 않은 경우.
  • 그룹 계층이 재배치된 경우.
  • 이슈와 머지 리퀘스트에 대한 일괄 업데이트가 있는 경우.

데이터가 가장 최근에 업데이트된 시점을 보려면 Edit 옆의 오른쪽 모서리에서 Last updated 배지를 호버합니다.

Stage 측정#

Value stream 분석은 시작 이벤트부터 종료 이벤트까지 각 Stage를 측정합니다. 종료 이벤트에 도달한 항목만 Stage 시간 계산에 포함됩니다.

기본적으로 차단된 이슈는 라이프사이클 개요에 포함되지 않습니다. 그러나 사용자 정의 레이블(예: workflow::blocked)을 사용하여 추적할 수 있습니다.

미리 정의된 이벤트를 기반으로 value stream 분석에서 Stage를 사용자 정의할 수 있습니다. 구성을 돕기 위해 GitLab은 템플릿으로 사용할 수 있는 미리 정의된 Stage 목록을 제공합니다. 예를 들어 이슈에 레이블을 추가할 때 시작하고 다른 레이블을 추가할 때 종료하는 Stage를 정의할 수 있습니다.

다음 표는 value stream 분석의 미리 정의된 Stage 개요를 제공합니다.

Stage 측정 방법
Issue 이슈를 생성하는 것과 레이블을 지정하거나 마일스톤에 추가하는 등 해결 조치를 취하는 것 사이의 중앙값 시간, 어느 것이 먼저 오든. 레이블에 이슈 보드 목록이 이미 생성된 경우에만 추적됩니다.
Plan 이전 Stage를 위해 취한 조치와 브랜치에 첫 번째 커밋을 푸시하는 것 사이의 중앙값 시간. 브랜치의 첫 번째 커밋이 PlanCode 사이의 분리를 트리거합니다. 브랜치의 커밋 중 하나 이상에는 관련 이슈 번호가 포함되어야 합니다 (예: #42). 브랜치의 커밋 중 어느 것도 관련 이슈 번호를 언급하지 않으면 Stage 측정 시간에서 고려되지 않습니다.
Code 첫 번째 커밋 푸시(이전 Stage)와 해당 커밋과 관련된 머지 리퀘스트(MR) 생성 사이의 중앙값 시간. 프로세스를 추적 상태로 유지하는 핵심은 머지 리퀘스트의 설명에 이슈 닫기 패턴을 포함시키는 것입니다. 예를 들어 Closes #xxx(여기서 xxx는 이 머지 리퀘스트와 관련된 이슈 번호). 닫기 패턴이 없으면 계산은 머지 리퀘스트의 첫 번째 커밋 생성 시간을 시작 시간으로 사용합니다.
Test 해당 프로젝트에 대한 전체 파이프라인을 실행하는 중앙값 시간. GitLab CI/CD가 해당 머지 리퀘스트에 푸시된 커밋에 대한 모든 job을 실행하는 데 걸리는 시간과 관련됩니다. 기본적으로 모든 파이프라인의 시작->완료 시간입니다.
Review 닫기 이슈 패턴이 있는 머지 리퀘스트를 생성부터 머지까지 검토하는 데 걸리는 중앙값 시간.
Staging 닫기 이슈 패턴이 있는 머지 리퀘스트를 머지하는 것부터 프로덕션 환경에 대한 첫 번째 배포까지의 중앙값 시간. 프로덕션 환경이 없으면 추적되지 않습니다.
Note

Value stream 분석은 타임스탬프 데이터로 작동하며 Stage의 최종 시작 및 중지 이벤트만 집계합니다. 여러 번 Stage 사이를 앞뒤로 이동하는 항목의 경우 Stage 시간은 최종 이벤트의 타임스탬프에서만 계산됩니다.

예시 워크플로#

이 예시는 하루에 7개 Stage를 모두 통과하는 워크플로를 보여줍니다.

Stage에 시작 시간과 중지 시간이 포함되지 않은 경우 해당 데이터는 중앙값 시간에 포함되지 않습니다. 이 예시에서는 마일스톤이 생성되고 테스트 및 환경 설정을 위한 CI/CD가 구성되었습니다.

  • 09:00: 이슈 생성. Issue Stage 시작.
  • 11:00: 이슈를 마일스톤(또는 백로그)에 추가하고, 이슈 작업을 시작하고, 로컬에서 브랜치 생성. Issue Stage 종료 및 Plan Stage 시작.
  • 12:00: 첫 번째 커밋 수행.
  • 12:30: 이슈 번호를 언급하는 브랜치에 두 번째 커밋 수행. Plan Stage 종료 및 Code Stage 시작.
  • 14:00: 브랜치 푸시 및 이슈 닫기 패턴이 포함된 머지 리퀘스트 생성. Code Stage 종료 및 TestReview Stage 시작.
  • GitLab CI/CD가 .gitlab-ci.yml 파일에 정의된 스크립트를 실행하는 데 5분 걸림.
  • 19:00: 머지 리퀘스트 머지. Review Stage 종료 및 Staging Stage 시작.
  • 19:30: production 환경에 대한 배포 완료. Staging 종료.

Value stream 분석은 각 Stage에 대해 다음 시간을 기록합니다:

  • Issue: 09:00부터 11:00까지: 2시간
  • Plan: 11:00부터 12:00까지: 1시간
  • Code: 12:00부터 14:00까지: 2시간
  • Test: 5분
  • Review: 14:00부터 19:00까지: 5시간
  • Staging: 19:00부터 19:30까지: 30분

이 예시와 관련된 다음 관찰 사항을 염두에 두세요:

  • 이 예시는 첫 번째 커밋이 이슈 번호를 언급하지 않아도 된다는 것을 보여줍니다. 작업 중인 브랜치의 이후 커밋에서 이를 수행할 수 있습니다.
  • Test Stage는 전체 사이클 시간 계산에 사용됩니다. 모든 MR은 테스트되어야 하기 때문에 Review 프로세스에 포함됩니다.
  • 이 예시는 7개 Stage 중 하나의 사이클만 보여줍니다. Value stream 분석 대시보드는 여러 사이클의 중앙값 시간을 보여줍니다.

누적 레이블 이벤트 기간#

히스토리
  • GitLab 16.9에서 enable_vsa_cumulative_label_duration_calculationvsa_duration_from_db라는 플래그를 사용하여 도입됨. 기본적으로 비활성화.
  • GitLab 16.10에서 GitLab.com 및 GitLab Self-Managed에서 활성화. 기능 플래그 vsa_duration_from_db 제거됨.
  • 기능 플래그 enable_vsa_cumulative_label_duration_calculation이 GitLab 17.0에서 제거됨.

이 기능을 사용하면 value stream 분석이 레이블 기반 Stage의 반복 이벤트 기간을 측정합니다. Stage의 시작 및 종료 이벤트 모두에 대한 레이블 제거 또는 추가 이벤트를 구성해야 합니다.

예를 들어 Stage가 in progress 레이블이 추가되고 제거되는 시기를 추적하는 경우, 다음 시간이 있습니다:

  • 9:00: 레이블 추가.
  • 10:00: 레이블 제거.
  • 12:00: 레이블 추가.
  • 14:00: 레이블 제거.

원래 계산 방법으로는 기간이 5시간입니다 (9:00부터 14:00까지). 누적 레이블 이벤트 기간 계산이 활성화되면 기간은 3시간입니다 (9:00부터 10:00까지 및 12:00부터 14:00까지).

Note

GitLab 버전을 16.10(또는 더 높은 버전)으로 업그레이드하면 기존 레이블 기반 value stream 분석 Stage가 백그라운드 집계 프로세스를 사용하여 자동으로 재집계됩니다.

업그레이드 후 데이터 재집계#

대규모 인스턴스에서 GitLab 버전을 업그레이드할 때, 특히 여러 마이너 버전을 건너뛰면 백그라운드 집계 프로세스가 더 오래 지속될 수 있습니다. 이 지연으로 인해 Value Stream Analytics 페이지의 데이터가 오래될 수 있습니다. 집계 프로세스를 가속화하고 오래된 데이터를 방지하려면 rails 콘솔에서 특정 그룹에 대한 동기 집계 스니펫을 호출할 수 있습니다:

group = Group.find(-1) # put your group id here
group_to_aggregate = group.root_ancestor

loop do
  cursor = {}
  context = Analytics::CycleAnalytics::AggregationContext.new(cursor: cursor)
  service_response = Analytics::CycleAnalytics::DataLoaderService.new(group: group_to_aggregate, model: Issue, context: context).execute

  if service_response.success? && service_response.payload[:reason] == :limit_reached
    cursor = service_response.payload[:context].cursor
  elsif service_response.success?
    puts "finished"
    break
  else
    puts "failed"
    break
  end
end

loop do
  cursor = {}
  context = Analytics::CycleAnalytics::AggregationContext.new(cursor: cursor)
  service_response = Analytics::CycleAnalytics::DataLoaderService.new(group: group_to_aggregate, model: MergeRequest, context: context).execute

  if service_response.success? && service_response.payload[:reason] == :limit_reached
    cursor = service_response.payload[:context].cursor
  elsif service_response.success?
    puts "finished"
    break
  else
    puts "failed"
    break
  end
end

프로덕션 환경#

Value stream 분석은 다음 패턴 중 하나와 일치하는 이름의 프로젝트 환경을 찾아 프로덕션 환경을 식별합니다:

  • prod 또는 prod/*
  • production 또는 production/*

이 패턴은 대소문자를 구분하지 않습니다.

GitLab CI/CD 구성에서 프로젝트 환경의 이름을 변경할 수 있습니다.

Value stream 분석 보기#

히스토리
  • 미리 정의된 날짜 범위 드롭다운 목록이 GitLab 16.5에서 vsa_predefined_date_ranges라는 플래그를 사용하여 도입됨. 기본적으로 비활성화.
  • 미리 정의된 날짜 범위 드롭다운 목록이 GitLab 16.7에서 GitLab Self-Managed 및 GitLab.com에서 활성화됨.
  • 미리 정의된 날짜 범위 드롭다운 목록이 GitLab 16.9에서 일반 사용 가능하게 됨. 기능 플래그 vsa_predefined_date_ranges 제거됨.

사전 요구 사항:

  • Reporter, Developer, Maintainer 또는 Owner 권한이 있어야 합니다.
  • 사용자 정의 value stream을 생성해야 합니다. Value stream 분석은 그룹 또는 프로젝트에 대해 생성된 사용자 정의 value stream만 표시합니다.

그룹 또는 프로젝트의 value stream 분석을 보려면:

  1. 상단 표시줄에서 Search or go to를 선택하고 프로젝트 또는 그룹을 찾습니다.
  2. 왼쪽 사이드바에서 Analyze > Value stream analytics를 선택합니다.
  3. 특정 Stage의 메트릭을 보려면 Filter results 텍스트 상자 아래의 Stage를 선택합니다.
  4. 선택 사항. 결과 필터링:
    1. Filter results 텍스트 상자를 선택합니다.

    2. 매개변수를 선택합니다.

    3. 결과를 좁히기 위한 값을 선택하거나 텍스트를 입력합니다.

    4. 특정 날짜 범위의 메트릭을 보려면 드롭다운 목록에서 미리 정의된 날짜 범위 또는 Custom 옵션을 선택합니다. Custom 옵션이 선택된 경우:

      • From 필드에서 시작 날짜를 선택합니다.
      • To 필드에서 종료 날짜를 선택합니다.

      차트와 목록은 날짜 범위 동안 생성된 워크플로 항목을 표시합니다.

  5. 선택 사항. 오름차순 또는 내림차순으로 결과 정렬:
    • 가장 최근 또는 가장 오래된 워크플로 항목으로 정렬하려면 Last event 헤더를 선택합니다.
    • 각 Stage에서 가장 많거나 가장 적은 시간이 소요된 것으로 정렬하려면 Duration 헤더를 선택합니다.

워크플로 항목 테이블 헤더 옆의 배지는 선택한 Stage 동안 완료된 워크플로 항목 수를 표시합니다.

테이블은 선택한 Stage에 대한 관련 워크플로 항목 목록을 표시합니다. 선택한 Stage에 따라 다음일 수 있습니다:

  • 이슈
  • 머지 리퀘스트
Note

각 미리 정의된 날짜 범위의 종료 날짜는 현재 날입니다. 이는 선택한 일수에 포함됩니다. 예를 들어 Last 30 days의 시작 날짜는 총 30일 동안 현재 날로부터 29일 전입니다.

데이터 필터#

특정 기준과 일치하는 데이터를 보기 위해 value stream 분석을 필터링할 수 있습니다. 다음 필터가 지원됩니다:

  • 날짜 범위
  • 프로젝트
  • 담당자
  • 작성자
  • 마일스톤
  • 레이블

Value stream 분석 메트릭#

Value stream 분석의 Overview 페이지는 프로젝트 및 그룹에 대한 DevSecOps 라이프사이클 성능의 주요 메트릭을 표시합니다.

라이프사이클 메트릭#

Value stream 분석에는 다음 라이프사이클 메트릭이 포함됩니다:

  • Lead time: 이슈가 생성된 시점부터 닫힌 시점까지의 중앙값 시간.
  • Cycle time: 이슈가 머지 리퀘스트의 커밋 메시지에 처음 참조된 시점부터 해당 참조된 이슈가 닫힌 시점까지의 중앙값 시간. 커밋 메시지에 이슈 번호 앞에 #을 포함해야 합니다 (예: #123). 그렇지 않으면 데이터가 표시되지 않습니다. 사이클 시간은 일반적으로 머지 리퀘스트가 첫 번째 커밋 후에 생성되기 때문에 리드 타임보다 짧습니다.
  • New issues: 생성된 새 이슈 수.
  • Deploys: 프로덕션에 대한 총 배포 수.

DORA 메트릭#

히스토리
  • GitLab 15.0에서 서비스 복구 시간 타일이 도입됨.
  • GitLab 15.0에서 변경 실패율 타일이 도입됨.

Value stream 분석에는 다음 DORA 메트릭이 포함됩니다:

  • 배포 빈도
  • 변경 리드 타임
  • 서비스 복구 시간
  • 변경 실패율

DORA 메트릭은 DORA API의 데이터를 기반으로 계산됩니다.

GitLab Premium 또는 Ultimate 구독이 있는 경우:

  • 성공한 배포 수는 DORA 데이터로 계산됩니다.
  • 데이터는 환경 및 환경 티어에 따라 필터링됩니다.

라이프사이클 및 DORA 메트릭 보기#

사전 요구 사항:

라이프사이클 메트릭을 보려면:

  1. 상단 표시줄에서 Search or go to를 선택하고 프로젝트 또는 그룹을 찾습니다.
  2. 왼쪽 사이드바에서 Analyze > Value stream analytics를 선택합니다. 라이프사이클 메트릭은 Filter results 텍스트 상자 아래에 표시됩니다.
  3. 선택 사항. 결과 필터링:
    1. Filter results 텍스트 상자를 선택합니다. 선택한 필터에 따라 대시보드가 자동으로 라이프사이클 메트릭을 집계하고 value stream 상태를 표시합니다.
    2. 매개변수를 선택합니다.
    3. 결과를 좁히기 위한 값을 선택하거나 텍스트를 입력합니다.
    4. 날짜 범위를 조정하려면:
      • From 필드에서 시작 날짜를 선택합니다.
      • To 필드에서 종료 날짜를 선택합니다.

Value Streams DashboardDORA 메트릭을 보려면:

  1. 상단 표시줄에서 Search or go to를 선택하고 프로젝트 또는 그룹을 찾습니다.
  2. 왼쪽 사이드바에서 Analyze > Value stream analytics를 선택합니다.
  3. Filter results 텍스트 상자 아래의 Lifecycle metrics 행에서 Value Streams Dashboard / DORA를 선택합니다.
  4. 선택 사항. 새 페이지를 열려면 그룹 URL에 이 경로 /analytics/dashboards/value_streams_dashboard를 추가합니다 (예: https://gitlab.com/groups/gitlab-org/-/analytics/dashboards/value_streams_dashboard).

각 개발 Stage의 메트릭 보기#

Value stream 분석은 각 개발 Stage에서 이슈 또는 머지 리퀘스트가 소요하는 중앙값 시간을 표시합니다.

그룹별로 각 Stage에서 소요된 중앙값 시간을 보려면:

  1. 상단 표시줄에서 Search or go to를 선택하고 프로젝트 또는 그룹을 찾습니다.
  2. 왼쪽 사이드바에서 Analyze > Value stream analytics를 선택합니다.
  3. 선택 사항. 결과 필터링:
    1. Filter results 텍스트 상자를 선택합니다.
    2. 매개변수를 선택합니다.
    3. 결과를 좁히기 위한 값을 선택하거나 텍스트를 입력합니다.
    4. 날짜 범위를 조정하려면:
      • From 필드에서 시작 날짜를 선택합니다.
      • To 필드에서 종료 날짜를 선택합니다.
  4. 각 Stage의 메트릭을 보려면 Filter results 텍스트 상자 위의 Stage를 호버합니다.
Note

날짜 범위 선택기는 이벤트 시간별로 항목을 필터링합니다. 이벤트 시간은 지정된 항목에 대해 선택한 Stage가 완료된 시점입니다.

유형별 작업 보기#

Tasks by type 차트는 그룹에 대해 하루에 완료된 작업(닫힌 이슈 및 머지된 머지 리퀘스트) 수를 누적으로 표시합니다.

차트는 전역 페이지 필터를 사용하여 선택한 그룹 및 시간 프레임을 기반으로 데이터를 표시합니다.

유형별 작업을 보려면:

  1. 상단 표시줄에서 Search or go to를 선택하고 그룹을 찾습니다.
  2. 왼쪽 사이드바에서 Analyze > Value stream analytics를 선택합니다.
  3. Filter results 텍스트 상자 아래에서 Overview를 선택합니다. Tasks by type 차트가 Total time 차트 아래에 표시됩니다.
  4. 선택 사항. 유형별로 작업을 필터링하려면 Settings (⚙️)를 선택한 다음 Issues 또는 Merge Requests를 선택합니다.
  5. 선택 사항. 레이블별로 작업을 필터링하려면 Settings (⚙️)를 선택한 다음 하나 이상의 레이블을 선택합니다. 기본적으로 상위 그룹 레이블(최대 10개)이 선택됩니다. 최대 15개의 레이블을 선택할 수 있습니다.

Value stream 생성#

히스토리
  • New value stream이 GitLab 16.10에서 vsa_standalone_settings_page라는 플래그를 사용하여 대화 상자에서 페이지로 변경됨. 기본적으로 비활성화.
  • GitLab 17.7에서 일반 사용 가능하게 됨. 기능 플래그 vsa_standalone_settings_page 제거됨.

기본 Stage로#

기본 Stage로 value stream을 생성하려면:

  1. 상단 표시줄에서 Search or go to를 선택하고 프로젝트 또는 그룹을 찾습니다.
  2. 왼쪽 사이드바에서 Analyze > Value Stream analytics를 선택합니다.
  3. New Value Stream을 선택합니다.
  4. Value stream 이름을 입력합니다.
  5. Create from default template을 선택합니다.
  6. 기본 Stage를 사용자 정의합니다:
    • Stage 순서를 변경하려면 위쪽 또는 아래쪽 화살표를 선택합니다.
    • Stage를 숨기려면 Hide ([eye-slash])를 선택합니다.
  7. 사용자 정의 Stage를 추가하려면 Add a stage를 선택합니다.
    • Stage 이름을 입력합니다.
    • Start eventStop event를 선택합니다.
  8. New value stream을 선택합니다.
Note

최근에 GitLab Premium으로 업그레이드한 경우 데이터를 수집하고 표시하는 데 최대 30분이 걸릴 수 있습니다.

사용자 정의 Stage로#

사용자 정의 Stage로 value stream을 생성하려면:

  1. 상단 표시줄에서 Search or go to를 선택하고 프로젝트 또는 그룹을 찾습니다.
  2. 왼쪽 사이드바에서 Analyze > Value Stream analytics를 선택합니다.
  3. New value stream을 선택합니다.
  4. 각 Stage에 대해:
    • Stage 이름을 입력합니다.
    • Start eventStop event를 선택합니다.
  5. 다른 Stage를 추가하려면 Add a stage를 선택합니다.
  6. Stage 순서를 변경하려면 위쪽 또는 아래쪽 화살표를 선택합니다.
  7. New value stream을 선택합니다.

비디오 설명은 Value Stream Analytics로 머지 리퀘스트 리뷰 프로세스 최적화를 참조하세요.

사용자 정의 Value stream의 레이블 기반 Stage#

복잡한 워크플로를 측정하기 위해 범위가 지정된 레이블을 사용할 수 있습니다. 예를 들어 스테이징 환경에서 프로덕션까지의 배포 시간을 측정하기 위해 다음 레이블을 사용할 수 있습니다:

  • 코드가 스테이징에 배포될 때 머지 리퀘스트에 workflow::staging 레이블이 추가됩니다.
  • 코드가 프로덕션에 배포될 때 머지 리퀘스트에 workflow::production 레이블이 추가됩니다.

Label-based value stream analytics stage

웹훅을 사용한 자동 데이터 레이블 지정#

GitLab 웹훅 이벤트를 사용하여 레이블을 자동으로 추가할 수 있습니다. 이를 통해 특정 이벤트가 발생할 때 머지 리퀘스트 또는 이슈에 레이블이 적용됩니다. 그런 다음 레이블 기반 Stage를 추가하여 워크플로를 추적할 수 있습니다. 구현에 대한 자세한 내용은 블로그 게시물 GitLab Labels 자동으로 적용하기를 참조하세요.

예시 구성#

Example configuration

이전 예시에서 Test Group(최상위 네임스페이스)에서 서로 다른 개발 워크플로를 사용하는 두 팀을 위해 두 개의 독립적인 value stream이 설정되었습니다.

첫 번째 value stream은 Stage 정의를 위한 표준 타임스탬프 기반 이벤트를 사용합니다. 두 번째 value stream은 레이블 이벤트를 사용합니다.

Value stream 편집#

히스토리
  • Edit value stream이 GitLab 16.10에서 vsa_standalone_settings_page라는 플래그를 사용하여 대화 상자에서 페이지로 변경됨. 기본적으로 비활성화.
  • GitLab 17.7에서 일반 사용 가능하게 됨. 기능 플래그 vsa_standalone_settings_page 제거됨.

Value stream을 생성한 후 목적에 맞게 사용자 정의할 수 있습니다. Value stream을 편집하려면:

  1. 상단 표시줄에서 Search or go to를 선택하고 프로젝트 또는 그룹을 찾습니다.
  2. 왼쪽 사이드바에서 Analyze > Value stream analytics를 선택합니다.
  3. Value stream 드롭다운 목록에서 편집하려는 value stream을 선택합니다.
  4. Value stream 드롭다운 목록 옆에서 Edit를 선택합니다.
  5. 선택 사항:
    • Value stream 이름 변경.
    • 기본 Stage 숨기거나 재정렬.
    • 기존 사용자 정의 Stage 제거.
    • 새 Stage를 추가하려면 Add a stage를 선택합니다.
    • Stage의 시작 및 종료 이벤트 선택.
  6. 선택 사항. 수정 사항을 실행 취소하려면 Restore value stream defaults를 선택합니다.
  7. Save Value Stream을 선택합니다.

Value stream 삭제#

사용자 정의 value stream을 삭제하려면:

  1. 상단 표시줄에서 Search or go to를 선택하고 프로젝트 또는 그룹을 찾습니다.
  2. 왼쪽 사이드바에서 Analyze > Value stream analytics를 선택합니다.
  3. Value stream 드롭다운 목록에서 삭제하려는 value stream을 선택하고 **Delete (value stream 이름)**을 선택합니다.
  4. 확인하려면 Delete를 선택합니다.

사이클 완료에 걸리는 일수 보기#

Total time chart는 개발 사이클이 완료되는 데 걸리는 평균 일수를 표시합니다. 차트는 마지막 500개의 워크플로 항목에 대한 데이터를 표시합니다.

  1. 상단 표시줄에서 Search or go to를 선택하고 프로젝트 또는 그룹을 찾습니다.
  2. 왼쪽 사이드바에서 Analyze > Value stream analytics를 선택합니다.
  3. Filter results 상자 위에서 Stage를 선택합니다:
    • 모든 Stage의 사이클 시간 요약을 보려면 Overview를 선택합니다.
    • 특정 Stage의 사이클 시간을 보려면 Stage를 선택합니다.
  4. 선택 사항. 결과 필터링:
    1. Filter results 텍스트 상자를 선택합니다.
    2. 매개변수를 선택합니다.
    3. 결과를 좁히기 위한 값을 선택하거나 텍스트를 입력합니다.
    4. 날짜 범위를 조정하려면:
      • From 필드에서 시작 날짜를 선택합니다.
      • To 필드에서 종료 날짜를 선택합니다.

액세스 권한#

Value stream 분석의 액세스 권한은 프로젝트 유형에 따라 다릅니다.

프로젝트 유형 권한
Public 누구나 액세스 가능.
Internal 인증된 모든 사용자가 액세스 가능.
Private Guest, Planner, Reporter, Developer, Maintainer 또는 Owner 권한이 있는 사용자가 액세스 가능.

Value Stream Analytics GraphQL API#

히스토리
  • GraphQL을 통한 Stage 메트릭 로딩이 GitLab 17.0에서 도입됨.

VSA GraphQL API를 사용하면 구성된 value stream 및 value stream Stage에서 메트릭을 요청할 수 있습니다. VSA 데이터를 외부 시스템이나 보고서로 내보내려는 경우 유용합니다.

다음 메트릭을 사용할 수 있습니다:

  • Stage에서 완료된 항목 수. 카운트는 최대 10,000개 항목으로 제한됩니다.
  • Stage에서 완료된 항목의 중앙값 기간.
  • Stage에서 완료된 항목의 평균 기간.

메트릭 요청#

사전 요구 사항:

  • Reporter, Developer, Maintainer 또는 Owner 권한이 있어야 합니다.

먼저 보고에 사용할 value stream을 결정해야 합니다.

그룹에 대해 구성된 value stream을 요청하려면 실행하세요:

group(fullPath: "your-group-path") {
  valueStreams {
    nodes {
      id
      name
    }
  }
}

마찬가지로 프로젝트에 대한 메트릭을 요청하려면 실행하세요:

project(fullPath: "your-project-path") {
  valueStreams {
    nodes {
      id
      name
    }
  }
}

Value stream Stage에 대한 메트릭을 요청하려면 실행하세요:

group(fullPath: "your-group-path") {
  valueStreams(id: "your-value-stream-id") {
    nodes {
      stages {
        id
        name
      }
    }
  }
}

데이터를 어떻게 사용할지에 따라 특정 Stage 또는 value stream의 모든 Stage에 대한 메트릭을 요청할 수 있습니다.

Note

모든 Stage에 대한 메트릭을 요청하면 일부 설치에서는 너무 느릴 수 있습니다. 권장되는 방법은 Stage별로 메트릭을 요청하는 것입니다.

Stage에 대한 메트릭 요청:

group(fullPath: "your-group-path") {
  valueStreams(id: "your-value-stream-id") {
    nodes {
      stages(id: "your-stage-id") {
        id
        name
        metrics(timeframe: { start: "2024-03-01", end: "2024-03-31" }) {
          average {
            value
            unit
          }
          median {
            value
            unit
          }
          count {
            value
            unit
          }
        }
      }
    }
  }
}
Note

항상 주어진 시간 프레임으로 메트릭을 요청해야 합니다. 지원되는 가장 긴 시간 프레임은 180일입니다.

metrics 노드는 추가 필터링 옵션을 지원합니다:

  • 담당자 사용자 이름
  • 작성자 사용자 이름
  • 레이블 이름
  • 마일스톤 제목

필터를 포함한 예시 요청:

group(fullPath: "your-group-path") {
  valueStreams(id: "your-value-stream-id") {
    nodes {
      stages(id: "your-stage-id") {
        id
        name
        metrics(
          labelNames: ["backend"],
          milestoneTitle: "17.0",
          timeframe: { start: "2024-03-01", end: "2024-03-31" }
        ) {
          average {
            value
            unit
          }
          median {
            value
            unit
          }
          count {
            value
            unit
          }
        }
      }
    }
  }
}

모범 사례#

  • 현재 상태의 정확한 보기를 얻으려면 시간 프레임이 종료되는 시점에 가능한 한 가깝게 메트릭을 요청합니다.
  • 정기적인 보고를 위해 스크립트를 만들고 예약된 파이프라인 기능을 사용하여 적시에 데이터를 내보낼 수 있습니다.
  • API를 호출하면 데이터베이스에서 현재 데이터를 가져옵니다. 시간이 지남에 따라 동일한 메트릭이 데이터베이스의 기본 데이터 변경으로 인해 변경될 수 있습니다. 예를 들어 그룹에서 프로젝트를 이동하거나 제거하면 그룹 수준 메트릭에 영향을 줄 수 있습니다.
  • 이전 기간의 메트릭을 다시 요청하고 이전에 수집된 메트릭과 비교하면 데이터의 왜곡을 보여줄 수 있어 변화하는 트렌드를 발견하고 설명하는 데 도움이 됩니다.

기능 가용성#

Value stream 분석은 FOSS 및 라이선스 버전의 프로젝트 및 그룹 수준에서 다양한 기능을 제공합니다.

  • GitLab Free에서 value stream 분석은 데이터를 집계하지 않습니다. 날짜 범위 필터가 이슈 및 머지 리퀘스트의 생성 날짜에 적용되는 데이터베이스를 직접 쿼리합니다. 미리 정의된 기본 Stage로 value stream 분석을 볼 수 있습니다.
  • GitLab Premium에서 value stream 분석은 데이터를 집계하고 종료 이벤트에 날짜 범위 필터를 적용합니다. Value stream을 생성, 편집 및 삭제할 수도 있습니다.
기능 그룹 수준 (라이선스) 프로젝트 수준 (라이선스) 프로젝트 수준 (FOSS)
사용자 정의 value stream 생성 아니오, 기본 Stage가 있는 하나의 value stream(기본)만 있음
사용자 정의 Stage 생성 아니오
필터링 (예: 작성자, 레이블, 마일스톤별)
Stage 시간 차트 아니오
총 시간 차트 아니오
유형별 작업 차트 아니오 아니오
DORA 메트릭 아니오
사이클 시간 및 리드 타임 요약 (라이프사이클 메트릭) 아니오
새 이슈, 커밋 및 배포 (라이프사이클 메트릭) 예, 커밋 제외
집계된 백엔드 사용 아니오
날짜 필터 동작 날짜 범위 내에 완료된 항목 필터링 생성 날짜별로 항목 필터링. 생성 날짜별로 항목 필터링.
권한 최소 reporter 최소 reporter 공개 가능

트러블슈팅#

Sidekiq cronjob:analytics_cycle_analytics에 의한 CPU 100% 사용#

Value stream 분석 백그라운드 job이 CPU 리소스를 독점하여 성능에 심각한 영향을 미칠 수 있습니다.

이 상황에서 복구하려면:

  1. Rails 콘솔에서 모든 프로젝트에 대해 기능을 비활성화하고 기존 job을 제거합니다:

    Project.find_each do |p|
      p.analytics_access_level='disabled';
      p.save!
    end
    
    Analytics::CycleAnalytics::GroupStage.delete_all
    Analytics::CycleAnalytics::Aggregation.delete_all
    
  2. 예를 들어 단일 feature_category=value_stream_management와 여러 feature_category!=value_stream_management 항목으로 Sidekiq 라우팅을 구성합니다. Enterprise Edition 목록에서 다른 관련 큐 메타데이터를 찾아보세요.

  3. 프로젝트 하나씩 value stream 분석을 활성화합니다. 성능 요구 사항에 따라 Sidekiq 라우팅을 추가로 조정해야 할 수 있습니다.