기능 가용성
가치 스트림 분석 작동 방식
가치 스트림 분석 보기
- 데이터 필터
가치 스트림 분석 지표
- 라이프사이클 지표
- DORA 지표
라이프사이클 및 DORA 지표 보기
각 개발 단계별 메트릭 보기
유형별 작업 보기
값 스트림 생성
- GitLab 기본 단계로 값 스트림 생성
- 사용자 정의 단계로 값 스트림 생성
  - 사용자 정의 값 스트림의 레이블 기반 단계
    - 웹훅을 사용한 자동 데이터 레이블링
  - 사용자 정의 값 스트림 구성 예시
값 스트림 편집
값 스트림 삭제
주기 완료에 필요한 일 수 보기
값 스트림 분석을 위한 접근 권한
값 스트림 분석 GraphQL API
- 메트릭 요청
- 모범 사례
값 스트림 예측을 통한 배포 빈도 예측
문제 해결
- Sidekiq cronjob:analytics_cycle_analytics에 의한 CPU 사용률 100%

가치 스트림 분석

Tier: Free, Premium, Ultimate Offering: GitLab.com, 자체 관리, GitLab Dedicated

가치 스트림 분석은 아이디어에서 제품으로 가는 시간을 측정합니다.

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

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

아이디어에서 제품으로 이동하는 데 걸리는 시간.
주어진 프로젝트의 속도.
개발 프로세스의 병목 현상.
오랜 기간 실행되는 문제 또는 병합 요청.
소프트웨어 개발 라이프사이클을 늦추는 요인.

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

끝에서 끝으로 DevSecOps 작업 흐름을 시각화합니다.
비효율성을 식별하고 해결합니다.
가치를 더 빨리 제공하기 위해 작업 흐름을 최적화합니다.

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

클릭해서 데모를 보려면 가치 스트림 관리 제품 투어를 참조하십시오.

기능 가용성

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

GitLab Free에서는 가치 스트림 분석이 데이터를 집계하지 않습니다. 데이터베이스를 직접 쿼리하며 날짜 범위 필터가 이슈와 병합 요청의 생성 날짜에 적용됩니다. 사용자는 미리 정의된 기본 단계로 가치 스트림 분석을 볼 수 있습니다.
GitLab Premium에서는 가치 스트림 분석이 데이터를 집계하고 종료 이벤트에 날짜 범위 필터를 적용합니다. 가치 스트림을 만들거나 편집하거나 삭제할 수도 있습니다.

기능	그룹 레벨 (라이센스)	프로젝트 레벨 (라이센스)	프로젝트 레벨 (FOSS)
사용자 정의 가치 스트림 생성	예	예	없음, 기본 단계로 하나의 가치 스트림만 있음
사용자 정의 단계 생성	예	예	아니요
필터링 (예: 작성자, 라벨, 마일스톤)	예	예	예
단계 시간 차트	예	예	아니요
총 시간 차트	예	예	아니요
유형별 작업 차트	예	아니요	아니요
DORA 메트릭	예	예	아니요
사이클 시간 및 리드 타임 요약 (라이프사이클 메트릭)	예	예	아니요
새 이슈, 커밋 및 배포 (라이프사이클 메트릭)	예, 커밋 제외	예	예
집계된 백엔드 사용	예	예	아니요
날짜 필터 동작	항목을 필터링하여 날짜 범위 내에서 완료	생성 날짜에 따라 항목 필터링	생성 날짜에 따라 항목 필터링
인증	최소한의 리포터 이상	최소한의 리포터 이상	공개일 수 있음

프로젝트 레벨의 기능적 동등성은 새로운 레코드 ProjectNamespace를 사용하여 달성됩니다. 이 통합 이니셔티브에 대한 자세한 내용은 조직 문서를 참조하십시오.

가치 스트림 분석 작동 방식

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

가치 스트림 분석은 세 가지 핵심 객체로 이루어져 있습니다:

가치 스트림은 가치 스트림 단계 목록을 포함합니다.
각 가치 스트림 단계 목록은 하나 이상의 단계를 포함합니다.
각 단계에는 시작 및 중지 두 가지 이벤트가 있습니다.

가치 스트림 단계

단계는 백엔드에서 정의된 페어링 규칙에서 소위 시작 및 종료 이벤트를 나타내는 이벤트 쌍입니다.

가치 스트림

가치 스트림은 단계의 컨테이너 객체입니다. DevOps 라이프사이클의 다양한 측면에 중점을 두기 위해 그룹당 여러 가치 스트림을 가질 수 있습니다.

가치 스트림 단계 이벤트

GitLab 17.2에 도입된 MR의 첫 번째 리뷰어 할당 이벤트. GitLab 17.2 이전에 생성 또는 업데이트된 MR에서 리뷰어 할당 이벤트를 보고할 수 없습니다.

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

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

이슈 닫힘
이슈 생성
이슈 첫 보드에 추가
이슈 첫 반복에 추가
이슈 첫 할당
이슈와 마일스톤 연결
이슈 첫 언급
이슈에 라벨 추가
이슈에서 라벨 제거
MR 닫힘
MR 병합
MR 생성
MR의 첫 커밋 시간
MR의 첫 할당
MR의 첫 리뷰어 할당
MR의 첫 배포
MR에 라벨 추가
MR에서 라벨 제거
MR의 마지막 파이프라인 지속 시간

이러한 이벤트는 시작 및 종료 이벤트의 타임스탬프에 의해 계산되는 기간 계산에서 중요한 역할을 합니다.

시작 및 종료 이벤트를 페어링할 수 있는 자세한 내용은 시작 및 종료 이벤트 유효성 검사를 참조하십시오.

가치 스트림 분석에서 데이터 집계하는 방법

Tier: Premium, Ultimate Offering: GitLab.com, 자체 관리, GitLab Dedicated

GitLab 15.0에 추가된 중지 날짜에 대한 필터링 활성화

가치 스트림 분석은 큰 그룹에서 큰 수의 이슈와 병합 요청을 위해 확장 가능하도록 데이터를 수집하고 집계하기 위해 백엔드 프로세스를 사용합니다. 이 프로세스로 인해 조치를 취한 시간(예: 이슈를 닫는 조치)과 데이터가 가치 스트림 분석 페이지에 표시되는 시간 사이에 약간의 지연이 발생할 수 있습니다.

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

가치 스트림을 아직 기본 단계로 생성하지 않았을 때 이 가치 스트림 분석 페이지를 처음 보는 경우.
그룹 계층 구조가 다시 정렬된 경우.
이슈 및 병합 요청에 대한 대량 업데이트가 있는 경우.

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

가치 스트림 분석이 단계를 측정하는 방법

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

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

가치 스트림 분석의 단계를 미리 정의된 이벤트를 기반으로 사용자 정의할 수 있습니다. 구성을 돕기 위해 GitLab은 템플릿으로 사용할 수 있는 미리 정의된 단계 목록을 제공합니다. 예를 들어, 이슈에 라벨을 추가하는 것으로 시작되고, 다른 라벨을 추가할 때까지 끝나는 단계를 정의할 수 있습니다.

다음 표는 가치 스트림 분석의 미리 정의된 단계에 대한 개요를 제공합니다.

단계	측정 방법
이슈	이슈를 생성하고 해결하기 위해 라벨을 지정하거나 마일스톤에 추가하는 작업 사이의 중앙 시간. 이슈에 대한 이슈 보드 목록이 이미 생성된 경우에만 라벨이 추적됩니다.
계획	이전 단계에 대한 작업과 브랜치로 첫 번째 커밋을 푸시하는 사이의 중앙 시간. 브랜치의 첫 번째 커밋은 계획과 코드 사이의 구분을 트리거합니다. 브랜치의 커밋 중 적어도 하나가 관련 이슈 번호를 포함해야 합니다(예: `#42`). 브랜치의 커밋 중 어느 것도 관련 이슈 번호를 언급하지 않으면 해당 스테이지에서의 측정 시간에는 포함되지 않습니다.
코드	첫 번째 커밋을 푸시하고 그 커밋과 관련된 병합 요청(MR)을 생성하는 사이의 중앙 시간. 프로세스를 추적하는 데 중요한 요소는 병합 요청 설명에 있는 이슈 닫기 패턴을 포함하는 것입니다. 예: `Closes #xxx`, 여기서 `xxx`는 병합 요청과 관련된 이슈 번호입니다. 닫기 패턴이 포함되지 않으면 계산에는 병합 요청의 첫 번째 커밋 시간을 시작 시간으로 사용합니다.
테스트	프로젝트의 전체 파이프라인을 실행하는 중앙 시간. 모든 파이프라인에 대해 GitLab CI/CD가 실행하는 시간에 관련됩니다. 기본적으로 모든 파이프라인의 시작->종료 시간입니다.
리뷰	닫기 이슈 패턴이 있는 병합 요청을 리뷰하는데 걸리는 중앙 시간. 병합 요청이 생성된 후 병합될 때까지의 시간입니다.
스테이징	닫기 이슈 패턴이 있는 병합 요청을 병합한 후 생산 환경으로 최초 배포까지의 중앙 시간. 생산 환경이없을 경우 추적되지 않습니다.

가치 스트림 분석은 타임스탬프 데이터에서 작동하며 단계의 최종 시작 및 중지 이벤트만을 집계합니다. 여러 번 단계 사이를 왕복하는 항목에 대해 단계 시간은 최종 이벤트의 타임스탬프만으로 계산됩니다.

가치 스트림 분석이 각 단계를 어떻게 계산하는지에 대한 정보는 가치 스트림 분석 개발 안내서를 참조하십시오.

#### 예시 작업 흐름

이 예시에서는 하루 동안 일곱 단계의 작업 흐름을 보여줍니다.

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

- 09:00: 이슈 생성. **이슈** 단계 시작.
- 11:00: 이슈를 이정표(또는 백로그)에 추가하고 해당 이슈에 대한 작업을 시작하고 지역적으로 브랜치를 생성합니다.
  **이슈** 단계 종료 및 **계획** 단계 시작.
- 12:00: 첫 번째 커밋 작성.
- 12:30: 이슈 번호를 언급하는 브랜치에 두 번째 커밋 작성.
  **계획** 단계 종료 및 **코드** 단계 시작.
- 14:00: 브랜치를 푸시하고 [이슈 마감 패턴](../../project/issues/managing_issues.md#closing-issues-automatically)이 포함된 병합 요청 생성.
  **코드** 단계 종료 및 **테스트** 및 **리뷰** 단계 시작.
- GitLab CI/CD는 [`.gitlab-ci.yml` 파일](../../../ci/yaml/index.md)에 정의된 스크립트를 실행하는 데 5분이 소요됩니다.
- 19:00: 병합 요청 병합. **리뷰** 단계 종료 및 **스테이징** 단계 시작.
- 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개 단계의 **하나의 주기**에 대해서만 설명합니다. 가치 스트림 분석 대시보드에서는 여러 주기에 대한 중앙값 시간이 표시됩니다.

#### 누적 라벨 이벤트 기간

> - [GitLab 16.9에서 도입](https://gitlab.com/gitlab-org/gitlab/-/issues/432576)된 `enable_vsa_cumulative_label_duration_calculation` 및 `vsa_duration_from_db`라는 플래그와 함께 사용. 기본적으로 비활성화됨.
> - [GitLab 16.10에서 GitLab.com 및 self-managed에서 활성화](https://gitlab.com/gitlab-com/gl-infra/production/-/issues/17476)됨. 기능 플래그 `vsa_duration_from_db`가 제거됨.
> - 기능 플래그 `enable_vsa_cumulative_label_duration_calculation`가 [제거됨](https://gitlab.com/gitlab-com/gl-infra/production/-/issues/17478) GitLab 17.0에서.

이 기능을 통해 가치 스트림 분석은 라벨 기반 단계의 반복 이벤트 기간을 측정합니다. 시작 이벤트 및 종료 이벤트에 대해 라벨 제거 또는 추가 이벤트를 구성해야 합니다.

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

- 9:00: 라벨 추가.
- 10:00: 라벨 제거.
- 12:00: 라벨 추가.
- 14:00 라벨 제거.

원래 계산 방법에 따르면, 기간은 5시간입니다 (9:00에서 14:00까지).
누적 라벨 이벤트 기간 계산이 활성화된 경우, 기간은 3시간입니다 (9:00에서 10:00까지 및 12:00에서 14:00까지).

참고:
GitLab 버전을 16.10(또는 해당 버전보다 높은 버전)으로 업그레이드하는 경우, 기존의 라벨 기반 가치 스트림 분석 단계는 백그라운드 집계 프로세스를 사용하여 자동으로 재집계됩니다.

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

DETAILS:
**Offering:** Self-managed

대규모 자체 관리 GitLab 인스턴스에서 GitLab 버전을 업그레이드하고 특히 여러 마이너 버전을 건너뛸 경우 백그라운드 집계 프로세스가 더 오랜 시간이 소요될 수 있습니다. 이 지연으로 인해 가치 스트림 분석 페이지의 데이터가 오래되어 보일 수 있습니다.
집계 프로세스를 가속화하고 오래된 데이터를 피하기 위해 [rails console](../../../administration/operations/rails_console.md#starting-a-rails-console-session)에서 다음과 같이 특정 그룹에 대해 동기화 집계 스니펫을 호출할 수 있습니다:

```ruby
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

가치 스트림 분석이 프로덕션 환경을 식별하는 방법

가치 스트림 분석은 프로덕션 환경을 프로젝트 환경 중 하나의 이름과 일치하는 패턴을 찾아서 식별합니다:

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

이러한 패턴은 대소문자를 가리지 않습니다.

GitLab CI/CD 구성에서 프로젝트 환경의 이름을 변경할 수 있습니다. ``` Keep the lines unchanged as much as possible :)

가치 스트림 분석 보기

GitLab 16.5에 도입된 사전 정의된 날짜 범위 드롭다운 목록은 vsa_predefined_date_ranges라는 플래그로 기본 설정으로 비활성화됩니다.
GitLab 16.7에서 자체 관리 및 GitLab.com에서 활성화된 사전 정의된 날짜 범위 드롭다운 목록이 있습니다.
GitLab 16.9에서 일반적으로 사용 가능한 사전 정의된 날짜 범위 드롭다운 목록이 있습니다. 기능 플래그 vsa_predefined_date_ranges가 제거되었습니다.

필수 조건:

적어도 기자 역할이 있어야 합니다.
사용자 지정 가치 스트림을 만들어야 합니다. 가치 스트림 분석은 당신의 그룹 또는 프로젝트에 대해 만든 사용자 지정 가치 스트림만 보여줍니다.

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

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

워크플로 항목 테이블 헤더 옆에 배지가 표시되며 해당 단계에서 완료된 워크플로 항목 수를 보여줍니다.

테이블에는 선택한 단계에 대한 관련 워크플로 항목 목록이 표시됩니다. 선택한 단계에 따라 다음과 같을 수 있습니다:

이슈
병합 요청

참고: 사전 정의된 각 날짜 범위의 종료일은 현재 날짜이며 선택한 날 수에 포함됩니다. 예를 들어, 지난 30일의 시작일은 현재 날로부터 29일 전으로 총 30일입니다.

데이터 필터

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

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

참고: “작업 유형별” 차트의 경우 날짜 범위 및 프로젝트 셀렉터 필터만 사용할 수 있습니다. 레이블 및 다른 필터가 적용되지 않으며 차트 옆의 드롭다운 목록에서 레이블을 별도로 선택해야 합니다.

가치 스트림 분석 지표

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

라이프사이클 지표

가치 스트림 분석에는 다음과 같은 라이프사이클 지표가 포함되어 있습니다:

리드 타임: 이슈 생성부터 닫힐 때까지의 중간 시간.
주기 시간: 첫 번째 커밋부터 이슈가 닫힐 때까지의 중간 시간. GitLab은 주기 시간을 연결된 이슈의 병합 요청에서 가장 이른 커밋부터 해당 이슈가 닫힐 때까지의 시간으로 측정합니다. 주기 시간 접근법은 항상 커밋 시간보다 늦게 병합 요청이 생성되기 때문에 리드 타임을 과소평가합니다.
새로운 이슈: 생성된 새로운 이슈의 수.
배포: 프로덕션으로의 총 배포 횟수.

DORA 지표

Tier: Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated

GitLab 15.0에서 서비스 복원 시간 타일이 도입되었습니다.
GitLab 15.0에 변경 실패율 타일이 도입되었습니다.

가치 스트림 분석에는 다음 DORA 지표가 포함되어 있습니다:

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

DORA 지표는 DORA API의 데이터를 기반으로 계산됩니다.

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

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

라이프사이클 및 DORA 지표 보기

필수 조건:

배포 지표를 보려면 프로덕션 환경을 구성해야 합니다.

라이프사이클 지표를 보려면:

왼쪽 사이드바에서 검색 또는 찾아가기를 선택하고 프로젝트 또는 그룹을 찾습니다.
분석 > 가치 스트림 분석을 선택합니다. 지표는 필터 결과 텍스트 상자 아래에 표시됩니다.
선택 사항. 결과를 필터링합니다:
1. 필터 결과 텍스트 상자를 선택합니다. 선택한 필터에 따라 대시보드는 자동으로 라이프사이클 지표를 집계하고 가치 스트림의 상태를 표시합니다.
2. 매개변수를 선택합니다.
3. 값을 선택하거나 결과를 미세 조정하기 위해 텍스트를 입력합니다.
4. 날짜 범위를 조정하려면:
  - 시작일에서 시작 날짜를 선택합니다.
  - 종료일에서 종료 날짜를 선택합니다.

가치 스트림 대시보드 및 DORA 지표를 보려면:

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

각 개발 단계별 메트릭 보기

값 스트림 분석은 각 개발 단계별로 이슈 또는 병합 요청에서 소요된 중앙값 시간을 보여줍니다.

그룹별로 각 단계별로 소요된 중앙값 시간을 보려면:

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

참고: 날짜 범위 선택기는 항목에 대한 이벤트 시간으로 항목을 필터링합니다. 이벤트 시간은 선택한 단계가 해당 항목에 대해 완료된 시간입니다.

유형별 작업 보기

세부정보: Tier: 프리미엄, 얼티메이트 Offering: GitLab.com, 셀프-매니지드, GitLab 전용

작업 유형 차트는 그룹의 하루에 대한 누적 이슈 및 병합 요청 수를 보여줍니다.

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

작업 유형을 보려면:

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

값 스트림 생성

세부정보: Tier: 프리미엄, 얼티메이트 Offering: GitLab.com, 셀프-매니지드, GitLab 전용

New value stream 기능은 GitLab 16.11에서 대화형에서 페이지로 변경되었습니다. vsa_standalone_settings_page라는 플래그로 기본적으로 비활성화되어 있습니다.

플래그: 셀프-매니지드 GitLab에서는 New value stream 기능이 기본적으로 사용할 수 없습니다. 사용하려면 관리자가 vsa_standalone_settings_page라는 기능 플래그를 활성화할 수 있습니다. GitLab.com 및 GitLab 전용에서는 이 기능을 사용할 수 없습니다. 이 기능은 운영에 즉시 사용할 수 있는 상태가 아닙니다.

GitLab 기본 단계로 값 스트림 생성

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

왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트 또는 그룹을 찾습니다.
분석 > 값 스트림 분석을 선택합니다.
새 값 스트림을 선택합니다.
값 스트림의 이름을 입력합니다.
기본 템플릿에서 생성을 선택합니다.
기본 단계를 사용자 정의하려면:
- 단계를 재정렬하려면 위 또는 아래 화살표를 선택합니다.
- 단계를 숨기려면 숨기기 ()를 선택합니다.
사용자 정의 단계를 추가하려면 다른 단계 추가를 선택합니다.
- 단계 이름을 입력합니다.
- 시작 이벤트 및 중지 이벤트를 선택합니다.
새 값 스트림을 선택합니다.

참고: GitLab 프리미엄으로 최근 업그레이드한 경우 데이터 수집 및 표시에 최대 30분이 걸릴 수 있습니다.

사용자 정의 단계로 값 스트림 생성

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

왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트 또는 그룹을 찾습니다.
분석 > 값 스트림 분석을 선택합니다.
새 값 스트림을 선택합니다.
각 단계별로:
- 단계 이름을 입력합니다.
- 시작 이벤트와 중지 이벤트를 선택합니다.
다른 단계를 추가하려면 다른 단계 추가를 선택합니다.
단계를 재정렬하려면 위 또는 아래 화살표를 선택합니다.
새 값 스트림을 선택합니다.

사용자 정의 값 스트림의 레이블 기반 단계

복잡한 워크플로우를 측정하기 위해 scoped 레이블을 사용할 수 있습니다. 예를 들어, 스테이징 환경에서 프로덕션으로의 배포 시간을 측정하려면 다음과 같은 레이블을 사용할 수 있습니다:

코드가 스테이징에 배포되면 병합 요청에 workflow::staging 레이블이 추가됩니다.
코드가 프로덕션에 배포되면 병합 요청에 workflow::production 레이블이 추가됩니다.

웹훅을 사용한 자동 데이터 레이블링

GitLab 웹훅 이벤트를 사용하여 특정 이벤트가 발생할 때 레이블이 병합 요청이나 이슈에 자동으로 적용될 수 있습니다. 그런 다음 레이블 기반 단계를 추가하여 워크플로우를 추적할 수 있습니다. 구현에 대해 자세히 알아보려면 블로그 글 GitLab 레이블 자동 적용을 참조하세요.

사용자 정의 값 스트림 구성 예시

위 예시에서는 테스트 그룹(최상위 네임스페이스)에서 서로 다른 개발 워크플로우를 사용하는 두 팀을 위해 독립된 값 스트림 두 개를 설정하였습니다.

첫 번째 값 스트림은 기본의 타임스탬프 기반 이벤트를 사용하여 단계를 정의합니다. 두 번째 값 스트림은 레이블 이벤트를 사용합니다.

값 스트림 편집

세부정보: Tier: 프리미엄, 얼티메이트 Offering: GitLab.com, 셀프-매니지드, GitLab 전용

값 스트림 편집 기능은 GitLab 16.11에서 대화형에서 페이지로 변경되었습니다. vsa_standalone_settings_page라는 플래그로 기본적으로 비활성화되어 있습니다.

플래그: 셀프-매니지드 GitLab에서는 값 스트림 편집 기능을 기본적으로 사용할 수 없습니다. 사용하려면 관리자가 vsa_standalone_settings_page라는 기능 플래그를 활성화할 수 있습니다. GitLab.com 및 GitLab 전용에서는 이 기능을 사용할 수 없습니다. 이 기능은 운영에 즉시 사용할 수 있는 상태가 아닙니다.

값 스트림을 만든 후 사용 목적에 맞게 사용자 정의할 수 있습니다. 값 스트림을 편집하려면:

왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트 또는 그룹을 찾습니다.
분석 > 값 스트림 분석을 선택합니다.
오른쪽 상단에서 드롭다운 목록을 선택한 다음 값 스트림을 선택합니다.
값 스트림 드롭다운 목록 옆에서 편집을 선택합니다.
선택 사항:
- 값 스트림의 이름을 변경합니다.
- 기본 단계를 숨기거나 재정렬합니다.
- 기존 사용자 정의 단계를 제거합니다.
- 새 단계를 추가하려면 다른 단계 추가를 선택합니다.
- 단계의 시작 및 끝 이벤트를 선택합니다.
선택 사항. 수행한 수정 사항을 복원하려면 값 스트림 기본값 복원을 선택합니다.
값 스트림 저장을 선택합니다.

값 스트림 삭제

Tier: 프리미엄, 얼티메이트 Offering: GitLab.com, Self-managed, GitLab Dedicated

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

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

주기 완료에 필요한 일 수 보기

Tier: 프리미엄, 얼티메이트 Offering: GitLab.com, Self-managed, GitLab Dedicated

전체 시간 차트는 개발 주기를 완료하는 데 소요되는 평균 일 수를 보여줍니다. 차트는 마지막 500개의 워크플로 항목에 대한 데이터를 보여줍니다.

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

값 스트림 분석을 위한 접근 권한

값 스트림 분석의 접근 권한은 프로젝트 유형에 따라 다릅니다.

프로젝트 유형	권한
공개	누구나 액세스할 수 있습니다.
내부	인증된 사용자는 누구나 액세스할 수 있습니다.
비공개	최소한 게스트 역할을 가진 사용자는 액세스할 수 있습니다.

값 스트림 분석 GraphQL API

Tier: 프리미엄, 얼티메이트 Offering: GitLab.com, Self-managed, GitLab Dedicated

GitLab 17.0에서 GraphQL을 통해 스테이지 메트릭 로드 작업이 소개되었습니다.

VSA GraphQL API를 사용하여 구성된 값 스트림 및 값 스트림 단계에서 메트릭을 요청할 수 있습니다. 이는 VSA 데이터를 외부 시스템으로 내보내거나 보고서를 작성하는 데 유용합니다.

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

스테이지에서 완료된 항목 수. 개수는 최대 10,000개로 제한됩니다.
스테이지에서 완료된 항목의 중앙 기간.
스테이지에서 완료된 항목의 평균 기간.

메트릭 요청

전제 조건:

적어도 리포터 역할을 가져야 합니다.

먼저 보고서에 사용할 값 스트림을 결정해야 합니다.

그룹의 구성된 값 스트림을 요청하려면 다음을 실행합니다:

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

마찬가지로 프로젝트의 메트릭을 요청하려면 다음을 실행합니다:

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

값 스트림의 단계에 대한 메트릭을 요청하려면 다음을 실행합니다:

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

데이터를 소비하는 방식에 따라 값 스트림의 한 특정 스테이지 또는 모든 스테이지에 대한 메트릭을 요청할 수 있습니다.

참고: 모든 스테이지에 대한 메트릭을 요청하는 것은 일부 설치에는 너무 느릴 수 있습니다. 권장되는 접근 방법은 스테이지별로 메트릭을 요청하는 것입니다.

스테이지에 대한 메트릭을 요청합니다:

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
          }
        }
      }
    }
  }
}

참고: 항상 지정된 시간 프레임 내에서 메트릭을 요청해야 합니다. 가장 긴 지원되는 시간 프레임은 180일입니다.

메트릭 노드는 추가 필터 옵션을 지원합니다:

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

필터와 함께 예시 요청:

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를 호출할 때 현재 데이터를 데이터베이스에서 받습니다. 준다는 시간이 흐름에 따라 데이터베이스의 기본 데이터가 변경되면 동일한 메트릭도 변할 수 있습니다. 예를 들어 프로젝트를 그룹에서 이동하거나 제거하는 경우 그룹 수준 메트릭에 영향을 줄 수 있습니다.
이전 기간에 대한 메트릭을 다시 요청하고 이전에 수집한 메트릭과 비교하면 데이터의 편향을 나타낼 수 있으며 변경된 동향을 발견하고 설명하는 데 도움이 될 수 있습니다.

값 스트림 예측을 통한 배포 빈도 예측

Tier: GitLab.com and Self-managed: 한정 기간 동안 얼티메이트. 2024년 10월 17일, GitLab Duo Enterprise를 사용한 얼티메이트. GitLab Dedicated: GitLab Duo Enterprise. Offering: GitLab.com, Self-managed, GitLab Dedicated Status: Experiment

GitLab 16.2에서 실험으로 소개되었습니다.

소프트웨어 개발 라이프사이클 전체에서 생산성 지표를 예측하고 이상을 식별하여 계획 및 의사 결정을 개선하세요.

필수 조건:

실험 및 베타 기능 설정이 활성화된 그룹에 속해 있어야 합니다.
CI/CD 분석을 보기 위한 권한이 있어야 합니다.

CI/CD Analytics에서 배포 빈도에 대한 예측 보기:

왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
분석 > CI/CD 분석을 선택합니다.
배포 빈도 탭을 선택합니다.
예측 표시 토글을 켭니다.
확인 대화 상자에서 테스트 조건 수락을 선택합니다.

예측은 차트에서 점선으로 표시됩니다. 데이터는 선택한 날짜 범위의 반만 예측됩니다.

예를 들어, 30일 범위를 선택하면 다음 15일의 예측이 표시됩니다.

이 실험적인 기능에 대한 피드백은 이슈 416833에서 제공하실 수 있습니다.

문제 해결

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

가능하다면, 가치 스트림 분석 백그라운드 작업은 CPU 자원을 독점함으로써 성능에 강력한 영향을 미칠 수 있습니다.

이 상황에서 회복하기 위해:

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

Project.find_each do |p|
  p.analytics_access_level='disabled';
  p.save!
end

Analytics::CycleAnalytics::GroupStage.delete_all
Analytics::CycleAnalytics::Aggregation.delete_all

Sidekiq 라우팅을 구성하여 예를 들어 단일 feature_category=value_stream_management 및 여러 feature_category!=value_stream_management 항목을 만듭니다. Enterprise Edition 목록에서 다른 관련 큐 메타데이터를 찾을 수 있습니다.
한 번에 한 프로젝트씩 가치 스트림 분석을 활성화합니다. 성능 요구 사항에 따라 Sidekiq 라우팅을 추가 조정해야 할 수 있습니다.

가치 스트림 분석

기능 가용성

가치 스트림 분석 작동 방식

가치 스트림 단계

가치 스트림

가치 스트림 단계 이벤트

가치 스트림 분석에서 데이터 집계하는 방법

가치 스트림 분석이 단계를 측정하는 방법

가치 스트림 분석이 프로덕션 환경을 식별하는 방법

가치 스트림 분석 보기

데이터 필터

가치 스트림 분석 지표

라이프사이클 지표

DORA 지표

라이프사이클 및 DORA 지표 보기

각 개발 단계별 메트릭 보기

유형별 작업 보기

값 스트림 생성

GitLab 기본 단계로 값 스트림 생성

사용자 정의 단계로 값 스트림 생성

사용자 정의 값 스트림의 레이블 기반 단계

웹훅을 사용한 자동 데이터 레이블링

사용자 정의 값 스트림 구성 예시

값 스트림 편집

값 스트림 삭제

주기 완료에 필요한 일 수 보기

값 스트림 분석을 위한 접근 권한

값 스트림 분석 GraphQL API

메트릭 요청

모범 사례

값 스트림 예측을 통한 배포 빈도 예측

문제 해결

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

도움말

기능 사용 가능성과 제품 평가판

도움받기

가치 스트림 분석

기능 가용성

가치 스트림 분석 작동 방식

가치 스트림 단계

가치 스트림

가치 스트림 단계 이벤트

가치 스트림 분석에서 데이터 집계하는 방법

가치 스트림 분석이 단계를 측정하는 방법

가치 스트림 분석이 프로덕션 환경을 식별하는 방법

가치 스트림 분석 보기

데이터 필터

가치 스트림 분석 지표

라이프사이클 지표

DORA 지표

라이프사이클 및 DORA 지표 보기

각 개발 단계별 메트릭 보기

유형별 작업 보기

값 스트림 생성

GitLab 기본 단계로 값 스트림 생성

사용자 정의 단계로 값 스트림 생성

사용자 정의 값 스트림의 레이블 기반 단계

웹훅을 사용한 자동 데이터 레이블링

사용자 정의 값 스트림 구성 예시

값 스트림 편집

값 스트림 삭제

주기 완료에 필요한 일 수 보기

값 스트림 분석을 위한 접근 권한

값 스트림 분석 GraphQL API

메트릭 요청

모범 사례

값 스트림 예측을 통한 배포 빈도 예측

문제 해결

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

도움말

기능 사용 가능성과 제품 평가판

도움받기

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