가치 스트림 분석

Tier: Free, Premium, Ultimate Offering: GitLab.com, Self-Managed, GitLab Dedicated

가치 스트림 분석은 아이디어에서 제품으로 가는 데 걸리는 시간을 메트릭합니다.

가치 스트림은 고객에게 가치를 전달하는 전체 작업 과정입니다. 예를 들어, DevOps 라이프사이클은 “관리” 단계에서 시작하여 “보호” 단계에서 끝나는 가치 스트림입니다.

가치 스트림 분석을 사용하여 다음을 확인하세요:

  • 아이디어에서 제품까지 걸리는 시간.
  • 특정 프로젝트의 속도.
  • 개발 프로세스의 병목 현상.
  • 지연되거나 오래 실행된 문제 또는 Merge Request.
  • 소프트웨어 개발 라이프사이클을 늦추는 요소.

가치 스트림 분석은 비즈니스에게 다음을 도와줍니다:

  • 최종 DevSecOps 워크스트림을 시각화합니다.
  • 비효율성을 확인하고 해결합니다.
  • 가치를 보다 빠르고 많이 전달하기 위해 작업 스트림을 최적화합니다.

가치 스트림 분석은 프로젝트 및 그룹에서 사용할 수 있습니다.

기능 가용성

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

  • GitLab Free에서 가치 스트림 분석은 데이터를 집계하지 않습니다. 데이터베이스에서 질의를 수행하며 날짜 범위 필터가 이슈와 Merge Request의 생성 날짜에 적용됩니다.
  • GitLab Premium에서 가치 스트림 분석은 데이터를 집계하고 종료 이벤트에 날짜 범위 필터를 적용합니다. 또한 사용자 지정 가치 스트림을 생성, 편집 및 삭제할 수 있습니다.
기능 그룹 수준(라이선스) 프로젝트 수준(라이선스) 프로젝트 수준(FOSS)
사용자 정의 가치 스트림 생성 가능 가능 불가능, 기본 단계의 유일한 가치 스트림이 기본 단계로 제공됩니다.
사용자 정의 단계 생성 가능 가능 불가능
필터링(예: 작성자, 레이블, 마일스톤) 가능 가능 가능
단계 시간 차트 가능 가능 불가능
전체 시간 차트 가능 가능 불가능
유형별 작업 차트 가능 불가능 불가능
DORA 메트릭 가능 가능 불가능
싸이클 타임 및 리드 타임 요약(라이프사이클 메트릭) 가능 가능 불가능
새로운 이슈, 커밋 및 배포(라이프사이클 메트릭) 커밋 포함하지 않음 가능 가능
집계된 백엔드 사용 가능 가능 불가능
날짜 필터 동작 항목을 날짜 범위 내에 완료한 것으로 필터링합니다. 항목을 생성 날짜로 필터링합니다. 항목을 생성 날짜로 필터링합니다.
인가 최소한의 보고자 이상 최소한의 보고자 이상 공개일 수 있음
note
그룹 수준 가치 스트림 분석의 프로젝트 수준과의 기능 동등성은 새로운 레코드 ProjectNamespace를 사용하여 달성됩니다. 이 통합 계획에 대한 자세한 내용은 Organization 문서를 참조하세요.

가치 스트림 분석 작동 방식

가치 스트림 분석은 소프트웨어 개발 프로세스의 각 단계의 기간을 계산합니다.

가치 스트림 분석은 세 가지 핵심 객체로 구성됩니다:

  • 가치 스트림은 가치 스트림 단계 디렉터리을 포함합니다.
  • 각 가치 스트림 단계 디렉터리은 하나 이상의 단계를 포함합니다.
  • 각 단계에는 시작 및 종료 2개의 이벤트가 있습니다.

가치 스트림 단계

단계는 추가 메타데이터(단계 이름과 같은)와 함께 이벤트 쌍(시작 및 종료 이벤트)를 나타냅니다. 단계는 백엔드에서 정의된 매칭 규칙에서 단계를 구성할 수 있습니다.

가치 스트림

가치 스트림은 단계를 위한 컨테이너 객체입니다. DevOps 라이프사이클의 다른 측면에 초점을 맞출 수 있는 여러 가치 스트림을 가질 수 있습니다.

가치 스트림 단계 이벤트

이벤트는 가치 스트림 분석 기능의 가장 작은 컴포넌트입니다. 단계는 시작 이벤트와 종료 이벤트로 구성됩니다.

다음과 같은 단계 이벤트가 있습니다:

  • 이슈 닫힘
  • 이슈 생성
  • 이슈 보드에 처음 추가
  • 이터레이션에 처음 추가된 이슈
  • 처음으로 할당된 이슈
  • 마일스톤과 연관된 이슈
  • 이슈에 처음 언급된 단어
  • 레이블이 추가된 이슈
  • 레이블이 제거된 이슈
  • Merge Request 닫힘
  • Merge Request Merge
  • Merge Request 생성
  • Merge Request의 첫 커밋 시간
  • 처음으로 할당된 Merge Request
  • Merge Request 최초 배포
  • Merge Request에 레이블 추가
  • Merge Request에서 레이블 제거
  • Merge Request의 마지막 파이프라인 지속 시간

이러한 이벤트는 기간 계산에서 핵심 역할을 하며 계산 방식은 다음과 같습니다: 기간 = 종료 이벤트 시간 - 시작 이벤트 시간.

시작 및 종료 이벤트를 어떻게 짝지을 수 있는지 알아보려면, 시작 및 종료 이벤트 유효성 검사를 참조하세요.

가치 스트림 분석이 데이터를 집계하는 방식

Tier: Premium, Ultimate Offering: GitLab.com, Self-Managed, GitLab Dedicated
  • GitLab 15.0에 추가된 종료 날짜에 대한 필터링을 활성화하세요.

가치 스트림 분석은 대량의 이슈와 Merge Request을 처리할 수 있도록 데이터를 수집하고 집계하기 위해 백엔드 프로세스를 사용합니다. 이를 통해 행동(예: 이슈 닫기)에서 데이터가 표시되기까지 약간의 지연이 발생할 수 있습니다.

데이터 처리 및 결과 표시에 최대 10분이 소요될 수 있습니다. 데이터 수집은 다음의 경우에 10분보다 오래 걸릴 수 있습니다.

  • 가치 스트림 분석을 처음 볼 때이고 아직 기본 단계로 가치 스트림을 생성하지 않은 경우.
  • 그룹 계층 구조가 재정렬된 경우.
  • 이슈 및 Merge Request에 대해 대량 업데이트가 있었을 경우.

데이터가 가장 최근에 업데이트된 시간을 보려면, 편집 옆의 오른쪽 모서리에 있는 최근 업데이트 배지 위로 마우스를 올리세요.

가치 스트림 분석이 단계를 메트릭하는 방법

가치 스트림 분석은 각 단계를 시작 이벤트에서 종료 이벤트까지 메트릭합니다. 종료 이벤트에 도달한 항목만 단계 시간 계산에 포함됩니다.

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

가치 스트림 분석에서 사전 정의된 이벤트를 기반으로 단계를 사용자 정의할 수 있습니다. 구성을 돕기 위해 GitLab은 템플릿으로 사용할 수 있는 사전 정의 단계 디렉터리을 제공합니다. 예를 들어, 이슈에 레이블을 추가할 때 시작되고 다른 레이블을 추가할 때 종료되는 단계를 정의할 수 있습니다.

다음 표는 가치 스트림 분석의 사전 정의 단계를 개요로 제공합니다.

단계 메트릭 방법
이슈 이슈가 생성되고 문제 해결 조치(예: 레이블 추가 또는 마일스톤에 추가) 사이의 중앙값 시간, 레이블이 이미 생성된 이슈 보드 디렉터리이 있는 경우에만 레이블이 추적됩니다.
계획 이전 단계에 대한 조치와 브랜치에 첫 번째 커밋을 푸시하는 시간 사이의 중앙값 시간. 브랜치의 첫 번째 커밋은 계획코드 사이의 분리를 유발합니다. 브랜치의 커밋 중 하나 이상에는 관련된 이슈 번호(예: #42)가 포함되어야 합니다. 브랜치의 커밋 중 이슈 번호를 언급하는 것이 없으면 해당 스테이지 메트릭 시간에 고려되지 않습니다.
코드 첫 번째 커밋을 푸시하는 시간(이전 단계)과 해당 커밋과 관련된 Merge Request(MR)를 생성하는 시간 사이의 중앙값 시간. 프로세스가 추적되도록 유지하는 키는 이슈 닫힘 패턴을 설명에 포함하는 것입니다. 예: Closes #xxx, 여기서 xxx는 해당 Merge Request과 관련된 이슈의 번호입니다. 종료 패턴이 없는 경우, 계산은 Merge Request의 첫 번째 커밋 작성 시간을 시작 시간으로 사용합니다.
테스트 해당 프로젝트의 모든 파이프라인을 실행하는 데 필요한 중앙값 시간. 이는 GitLab CI/CD가 해당 Merge Request에 푸시된 모든 작업을 실행하는 데 걸리는 시간과 관련이 있습니다. 이것은 기본적으로 모든 파이프라인의 시작->종료 시간입니다.
검토 Merge Request을 검토하는 데 걸리는 중앙값 시간(닫힌 이슈 패턴을 가지고 있으며 생성된 후 Merge될 때까지).
스테이징 Merge Request이 닫힌 이슈 패턴을 가지고 있으며 처음으로 배포가 이루어질 때까지의 중앙값 시간. 프로덕션 환경에 대한 첫 번째 배포는 추적되지 않습니다.
note
가치 스트림 분석은 타임스탬프 데이터를 기반으로 하며 단계의 최종 시작 및 종료 이벤트만 집계합니다. 단계간에 여러 번 이동하는 항목에 대해, 단계 시간은 최종 이벤트의 타임스탬프만으로 계산됩니다.

가치 스트림 분석이 각 단계를 계산하는 방법에 대한 자세한 정보는 가치 스트림 분석 개발 가이드를 참조하세요.

예시 작업 흐름

이 예시에서는 1일 동안의 모든 7단계를 거친 작업 흐름을 보여줍니다.

단계에 시작 및 종료 시간이 포함되지 않은 경우, 해당 데이터는 중간 시간에 포함되지 않습니다. 이 예시에서는 마일스톤을 만들었으며, 테스트 및 환경 설정을 위한 CI/CD가 구성되었습니다.

  • 09:00: 이슈 생성. 이슈 단계 시작.
  • 11:00: 이슈를 마일스톤(또는 백로그)에 추가하고, 이슈에 대한 작업을 시작하고 로컬로 브랜치를 생성합니다. 이슈 단계 종료 및 계획 단계 시작.
  • 12:00: 첫 번째 커밋.
  • 12:30: 이슈 번호를 언급하는 브랜치에 두 번째 커밋을 합니다. 계획 단계 종료 및 코드 단계 시작.
  • 14:00: 브랜치를 푸시하고, 이슈 클로징 패턴을 포함하는 Merge Request을 생성합니다 이슈 클로진 패턴을 참조합니다. 코드 단계 종료 및 테스트리뷰 단계 시작.
  • GitLab CI/CD가 .gitlab-ci.yml 파일에 정의된 스크립트를 실행하는 데 5분이 걸립니다.
  • 19:00: Merge Request을 Merge합니다. 리뷰 단계 종료 및 스테이징 단계 시작.
  • 19:30: production 환경으로의 배포가 완료됩니다. 스테이징 종료.

가치 스트림 분석은 각 단계에 대해 다음과 같은 시간을 기록합니다:

  • 이슈: 09:00 - 11:00: 2시간
  • 계획: 11:00 - 12:00: 1시간
  • 코드: 12:00 - 14:00: 2시간
  • 테스트: 5분
  • 리뷰: 14:00 - 19:00: 5시간
  • 스테이징: 19:00 - 19:30: 30분

이 예시와 관련된 다음 관찰 사항을 명심하세요:

  • 첫 번째 커밋에 이슈 번호가 언급되지 않아도 괜찮습니다. 나중에 작업 중인 브랜치의 모든 커밋에서 할 수 있습니다.
  • 테스트 단계는 주기의 전반적인 시간 계산에 사용됩니다. 모든 MR은 테스트되어야 하므로 리뷰 프로세스에 포함됩니다.
  • 이 예시는 7단계의 한 주기만을 보여줍니다. 가치 스트림 분석 대시보드는 다중 주기에 대한 중간 시간을 보여줍니다.

누적 라벨 이벤트 기간

이 기능을 사용하면 가치 스트림 분석이 라벨 기반 단계의 반복 이벤트 기간을 메트릭합니다. 시작 및 종료 이벤트에 대한 라벨 제거 또는 추가 이벤트를 구성해야 합니다.

예를 들면, 다음과 같은 시간에 진행 중 라벨이 추가되고 제거될 때 단계가 추적됩니다:

  • 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(또는 그 이상)으로 업그레이드하면 기존의 라벨 기반 가치 스트림 분석 단계가 백그라운드 집계 프로세스를 사용하여 자동으로 재집계됩니다.

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

Offering: Self-Managed

대규모 Self-Managed형 GitLab 인스턴스에서 GitLab 버전을 업그레이드할 때 특히 여러 마이너 버전을 건너뛸 경우, 백그라운드 집계 프로세스가 더 오래 소요될 수 있습니다. 이 지연으로 인해 가치 스트림 분석 페이지의 데이터가 오래되어 보일 수 있습니다. 집계 프로세스를 가속화하고 오래된 데이터를 피하기 위해 Rails 콘솔에서 특정 그룹에 대해 동기화 집계 스니펫을 호출할 수 있습니다:

group = Group.find(-1) # 여기에 그룹 ID를 입력하세요.
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 "완료"
    break
  else
    puts "실패"
    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 "완료"
    break
  else
    puts "실패"
    break
  end
end

가치 스트림 분석이 어떻게 production 환경을 식별하는지

가치 스트림 분석은 프로덕션 환경을 식별하기 위해 프로젝트 환경에서 다음과 같은 패턴과 일치하는 이름을 찾습니다:

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

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

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

가치 스트림 분석 보기

  • 사전 정의된 날짜 범위 드롭다운 디렉터리은 GitLab 16.5에 도입, 사용되는 플래그: vsa_predefined_date_ranges. 기본 비활성화 상태.
  • 사전 정의된 날짜 범위 드롭다운 디렉터리은 GitLab 16.7에서 셀프-관리 및 GitLab.com에 활성화.
  • 사전 정의된 날짜 범위 드롭다운 디렉터리은 GitLab 16.9에 일반적으로 사용 가능 함. 플래그 vsa_predefined_date_ranges 제거됨.

전제 조건:

  • 적어도 기록자 역할이 있어야 합니다.
  • 사용자 지정 가치 스트림을 만들어야 합니다. 가치 스트림 분석은 그룹 또는 프로젝트에 대해 만들어진 사용자 지정 가치 스트림만 표시합니다.

그룹 또는 프로젝트에서 가치 스트림 분석을 보려면:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하여 프로젝트 또는 그룹을 찾습니다.
  2. 분석 > 가치 스트림 분석을 선택합니다.
  3. 특정 단계의 지표를 보려면 필터 결과 텍스트 상자 아래에서 단계를 선택합니다.
  4. 선택적으로 결과를 필터링합니다:
    1. 필터 결과 텍스트 상자를 선택합니다.
    2. 매개변수를 선택합니다.
    3. 결과를 정제하려면 값을 선택하거나 텍스트를 입력합니다.
    4. 특정 날짜 범위에서 지표를 보려면 드롭다운 디렉터리에서 사전 정의된 날짜 범위 또는 사용자 정의 옵션을 선택합니다. 사용자 정의 옵션을 선택하면:
      • 시작일에서 시작 날짜를 선택합니다.
      • 종료일에서 종료 날짜를 선택합니다. 차트와 디렉터리에는 날짜 범위에서 생성된 작업 항목이 표시됩니다.
  5. 선택적으로 오름차순 또는 내림차순으로 결과를 정렬합니다:
    • 최근 또는 가장 오래된 작업 항목으로 정렬하려면 최신 이벤트 헤더를 선택합니다.
    • 각 단계에서 소요된 시간이 가장 많은 또는 가장 적은 것으로 정렬하려면 기간 헤더를 선택합니다.

작업 테이블 헤더 옆에 배지가 표시되어 선택한 단계에서 완료된 작업 항목의 수를 보여줍니다.

테이블에는 선택한 단계에 대한 관련 작업 항목 디렉터리이 표시됩니다. 선택한 단계에 따라 다음 항목 중 하나가 표시될 수 있습니다:

  • 이슈
  • Merge Request

데이터 필터

특정 기준과 일치하는 데이터를 볼 수 있도록 가치 스트림 분석을 필터링할 수 있습니다. 다음 필터가 지원됩니다:

  • 날짜 범위
  • 프로젝트
  • 담당자
  • 작성자
  • 마일스톤
  • 라벨
note
“작업 유형” 차트의 경우, 날짜 범위 및 프로젝트 선택기 필터만 사용할 수 있습니다. 라벨 및 기타 필터는 적용되지 않으며 차트 옆의 드롭다운 디렉터리에서 라벨을 별도로 선택해야 합니다.

가치 스트림 분석 메트릭

가치 스트림 분석의 개요 페이지에는 프로젝트 및 그룹의 DevSecOps 라이프사이클 성능의 주요 메트릭이 표시됩니다.

라이프사이클 메트릭

가치 스트림 분석에는 다음과 같은 라이프사이클 메트릭이 포함됩니다:

  • 리드 타임: 문제 생성부터 종료까지의 중간 시간.
  • 사이클 타임: 첫 번째 커밋부터 문제 종료까지의 중간 시간. GitLab은 연결된 문제의 Merge Request의 가장 이른 커밋부터 해당 문제가 닫힐 때까지의 사이클 시간을 메트릭합니다. Merge Request 생성은 항상 커밋 시간보다 나중이기 때문에 사이클 시간 접근은 리드 타임을 과소평가합니다.
  • 새로운 문제: 생성된 새 문제의 수.
  • 배포: 프로덕션으로의 총 배포 횟수.

DORA 메트릭

Tier: Ultimate Offering: GitLab.com, Self-Managed, GitLab Dedicated
  • GitLab 15.0에서 서비스 복구 시간 타일을 도입했습니다.
  • GitLab 15.0에서 변경 실패율 타일을 도입했습니다.

가치 스트림 분석에는 다음 DORA 메트릭이 포함됩니다:

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

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

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

  • 성공적인 배포 횟수는 DORA 데이터를 기반으로 계산됩니다.
  • 데이터는 환경 및 환경 티어를 기반으로 필터링됩니다.

각개화 단계별 메트릭 보기

가치 스트림 분석은 각 개발 단계에서 문제 또는 Merge Request이 소요한 중간 시간을 보여줍니다.

특정 그룹에서 각 단계에서 소요된 중간 시간을 보려면:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트 또는 그룹을 찾습니다.
  2. 분석 > 가치 스트림 분석을 선택합니다.
  3. 선택적. 결과를 필터링합니다:
    1. 결과 필터 텍스트 상자를 선택합니다.
    2. 매개변수를 선택합니다.
    3. 결과를 세분화하려면 값을 선택하거나 입력합니다.
    4. 날짜 범위를 조정하려면:
      • 시작일에서 시작 날짜를 선택합니다.
      • 종료일에서 종료 날짜를 선택합니다.

가치 스트림 대시보드DORA 메트릭을 보려면:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트 또는 그룹을 찾습니다.
  2. 분석 > 가치 스트림 분석을 선택합니다.
  3. 결과 필터 텍스트 상자 아래의 라이프사이클 메트릭 행에서 가치 스트림 대시보드 / DORA를 선택합니다.
  4. 새 페이지를 열려면 그룹 URL에 이 경로 /analytics/dashboards/value_streams_dashboard를 추가합니다 (예: https://gitlab.com/groups/gitlab-org/-/analytics/dashboards/value_streams_dashboard).

작업 유형별로 보기

Tier: Premium, Ultimate Offering: GitLab.com, Self-Managed, GitLab Dedicated

작업 유형 차트는 그룹에서 일일 문제 및 Merge Request의 누적 수를 표시합니다.

차트는 전역 페이지 필터를 사용하여 선택된 그룹 및 시간 프레임에 따라 데이터를 표시합니다.

작업 유형을 보려면:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
  2. 분석 > 가치 스트림 분석을 선택합니다.
  3. 결과 필터 텍스트 상자 아래에서 개요를 선택합니다. 작업 유형 차트는 총 시간 차트 아래에 표시됩니다.
  4. 작업 유형을 전환하려면 설정 () 드롭다운 디렉터리을 선택하고 문제 또는 Merge Request을 선택합니다.
  5. 라벨을 추가하거나 제거하려면 설정 () 드롭다운 디렉터리을 선택하고 라벨을 선택하거나 검색합니다. 기본적으로 최대 10개의 최상위 그룹 레벨 라벨이 선택됩니다. 최대 15개의 라벨을 선택할 수 있습니다.

가치 스트림 생성

Tier: Premium, Ultimate Offering: GitLab.com, Self-Managed, GitLab Dedicated

플래그: 자체 호스팅 GitLab의 기본적으로 새 가치 스트림 기능은 사용할 수 없습니다. 사용하려면 관리자가 vsa_standalone_settings_page라는 플래그를 활성화해야 합니다. GitLab.com 및 GitLab Dedicated에서는 이 기능을 사용할 수 없습니다. 이 기능은 상용 환경에 사용할 수 없습니다.

GitLab 기본 단계로 가치 스트림 생성

가치 스트림을 생성할 때, GitLab의 기본 단계를 사용하고 숨기거나 재정렬할 수 있습니다. 또한 기본 템플릿에서 제공되는 것에 추가하여 사용자 정의 단계를 생성할 수도 있습니다.

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트 또는 그룹을 찾습니다.
  2. 분석 > 가치 스트림 분석을 선택합니다.
  3. 새 가치 스트림을 선택합니다.
  4. 가치 스트림에 이름을 입력합니다.
  5. 기본 템플릿에서 생성을 선택합니다.
  6. 기본 단계를 사용자 정의하려면:
    • 단계를 다시 정렬하려면 위 또는 아래 화살표를 선택합니다.
    • 단계를 숨기려면 숨김 ()을 선택합니다.
  7. 사용자 정의 단계를 추가하려면 다른 단계 추가를 선택합니다.
    • 단계에 이름을 입력합니다.
    • 시작 이벤트종료 이벤트를 선택합니다.
  8. 새 가치 스트림을 선택합니다.
note
GitLab Premium으로 최근에 업그레이드한 경우, 데이터 수집 및 표시에 최대 30분이 소요될 수 있습니다.

======== ### Create a value stream with custom stages

사용자 정의 단계로 가치 스트림 만들기

가치 스트림을 만들 때 자체 개발 워크플로와 일치하는 사용자 정의 단계를 만들고 추가할 수 있습니다.

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트 또는 그룹을 찾습니다.
  2. 분석 > 가치 스트림 분석을 선택합니다.
  3. 새 가치 스트림을 선택합니다.
  4. 각 단계에 대해:
    • 단계의 이름을 입력합니다.
    • 시작 이벤트중지 이벤트를 선택합니다.
  5. 다른 단계를 추가하려면 다른 단계 추가를 선택합니다.
  6. 단계를 재정렬하려면 위 또는 아래 화살표를 선택합니다.
  7. 새 가치 스트림을 선택합니다.

사용자 정의 가치 스트림을 위한 레이블 기반 단계

복잡한 작업 흐름을 메트릭하기 위해 스코프가 지정된 레이블을 사용할 수 있습니다. 예를 들어, 스테이징 환경에서 프로덕션으로의 배포 시간을 메트릭하려면 다음과 같은 레이블을 사용할 수 있습니다:

  • 코드가 스테이징에 배포되면, workflow::staging 레이블이 Merge Request에 추가됩니다.
  • 코드가 프로덕션에 배포되면, workflow::production 레이블이 Merge Request에 추가됩니다.

레이블 기반 가치 스트림 분석 단계

사용자 정의 가치 스트림 구성 예

예시 구성

위의 예에서, 서로 다른 개발 작업 흐름을 사용하는 두 팀을 위해 두 개의 독립적인 가치 스트림이 Test Group(최상위 네임스페이스)에서 설정되어 있습니다.

첫 번째 가치 스트림은 단계를 정의하기 위해 표준 타임스탬프 기반 이벤트를 사용합니다. 두 번째 가치 스트림은 레이블 이벤트를 사용합니다.

가치 스트림 편집

Tier: Premium, Ultimate Offering: GitLab.com, Self-Managed, GitLab Dedicated
  • Edit value stream 기능은 변경되어 GitLab 16.11에서 vsa_standalone_settings_page라는 플래그와 함께 다이얼로그에서 페이지로 변환되었습니다. 기본적으로 비활성화됩니다.
Self-Managed GitLab의 경우, 기본적으로 Edit value stream 기능을 사용할 수 없습니다. 사용하려면 관리자가 vsa_standalone_settings_page라는 피처 플래그를 활성화할 수 있습니다. GitLab.com 및 GitLab Dedicated에서는 이 기능을 사용할 수 없습니다. 이 기능은 아직 제품 사용에 적합하지 않습니다.

가치 스트림을 생성한 후에는 목적에 맞게 사용자 정의할 수 있습니다. 가치 스트림을 편집하려면:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트나 그룹을 찾습니다.
  2. 분석 > 가치 스트림 분석을 선택합니다.
  3. 오른쪽 상단 모서리에서 드롭다운 디렉터리을 선택한 다음, 가치 스트림을 선택합니다.
  4. 가치 스트림 드롭다운 디렉터리 옆에서 편집을 선택합니다.
  5. 선택 사항:
    • 가치 스트림의 이름을 변경합니다.
    • 기본 단계 숨기거나 재정렬합니다.
    • 기존 사용자 정의 단계를 제거합니다.
    • 새로운 단계를 추가하려면 다른 단계 추가를 선택합니다.
    • 단계의 시작 및 종료 이벤트를 선택합니다.
  6. 선택 사항. 모든 수정을 원래 값으로 되돌리려면 값 스트림 기본값 복원을 선택합니다.
  7. 값 스트림 저장을 선택합니다.

값 스트림 삭제

DETAILS:

Tier: Premium, 궁극 Offering: GitLab.com, Self-Managed, GitLab Dedicated

사용자 정의 값 스트림을 삭제하려면:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트 또는 그룹을 찾습니다.
  2. 오른쪽 상단 모서리에서 드롭다운 디렉터리을 선택한 다음, 삭제하려는 값 스트림을 선택합니다.
  3. 삭제 (값 스트림 이름)을 선택합니다.
  4. 확인하려면 삭제를 선택합니다.

값 스트림 삭제

주기 완료 일 수 보기

DETAILS:

Tier: Premium, 궁극 Offering: GitLab.com, Self-Managed, GitLab Dedicated

총 시간 차트는 개발 주기가 완료되는 데 걸리는 평균 일 수를 보여줍니다.

차트는 마지막 500개 워크플로 항목에 대한 데이터를 보여줍니다.

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트 또는 그룹을 찾습니다.
  2. 분석 > 가치 스트림 분석을 선택합니다.
  3. 결과 필터 상자 위에서 단계를 선택합니다:
    • 모든 단계의 사이클 타임 요약을 보려면 개요를 선택합니다.
    • 특정 단계의 사이클 타임을 보려면 해당 단계를 선택합니다.
  4. 선택 사항. 결과를 필터링합니다:
    1. 결과 필터 텍스트 상자를 선택합니다.
    2. 매개변수를 선택합니다.
    3. 결과를 미세 조정하려면 값을 선택하거나 텍스트를 입력합니다.
    4. 날짜 범위를 조정하려면:
      • 시작일 필드에서 시작 날짜를 선택합니다.
      • 종료일 필드에서 종료 날짜를 선택합니다.

값 스트림 분석을 위한 액세스 권한

값 스트림 분석에 대한 액세스 권한은 프로젝트 유형에 따라 달라집니다.

프로젝트 유형 권한
Public 누구나 액세스할 수 있습니다.
Internal 인증된 사용자는 누구나 액세스할 수 있습니다.
Private 적어도 게스트 역할을 가진 사용자는 누구나 액세스할 수 있습니다.

문제 해결

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

값 스트림 분석 백그라운드 작업이 CPU 자원을 독점하여 성능에 강력한 영향을 미칠 수 있습니다.

이 상황에서 회복하려면:

  1. Rails 콘솔에서 모든 프로젝트의 기능을 비활성화하고 기존 작업을 삭제합니다:

    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. 프로젝트마다 하나씩 값을 스트림 분석을 활성화합니다. 성능 요구 사항에 따라 Sidekiq 라우팅을 더 조정해야 할 수 있습니다.