소프트웨어 개발 수명 주기 데이터 템플릿
소프트웨어 개발 수명 주기 데이터 템플릿
- 수집 권장 속성
- 추적할 주요 활동
- 데이터 추출 안내
소프트웨어 개발 수명 주기 속성
| 이름 | 설명 | ||
|---|---|---|---|
|
개발 항목
DevelopmentItem
|
기능, 버그 수정, 작업 등 작업 단위를 식별하는 고유 ID로, 기본 케이스 식별자로 사용됩니다. | ||
|
설명
개발 항목은 소프트웨어 개발 수명 주기에서 진행되는 개별 작업 단위입니다. 생성부터 최종 배포까지 관련 활동을 하나의 케이스로 연결합니다. GitLab에서는 일반적으로 프로젝트 내에서 고유한 이슈 내부 ID(IID)로 나타냅니다. 개발 항목별로 분석하면 전체 주기 시간을 측정하고 병목을 찾으며 프로세스 준수 여부를 확인할 수 있습니다. 이를 바탕으로 아이디어부터 프로덕션까지 작업이 얼마나 효율적으로 전달되는지 파악할 수 있습니다.
중요한 이유
프로세스 이벤트를 하나로 연결하는 필수 케이스 식별자입니다. 이를 통해 각 작업 항목의 전체 수명 주기를 추적할 수 있습니다.
확보 방법
일반적으로 GitLab 이슈의 내부 ID(IID)를 사용합니다. Issues API 응답의 'iid' 필드에서 확인할 수 있습니다.
예시
1024512PRJ-2345
|
|||
|
시작 시각
StartTime
|
활동이나 이벤트가 시작된 시점을 나타내는 타임스탬프입니다. | ||
|
설명
StartTime은 특정 활동이 발생한 날짜와 시각을 정확히 나타냅니다. GitLab 이벤트에서는 여러 타임스탬프 필드에 기록됩니다. 예를 들어 '이슈 생성' 활동의 StartTime은 이슈의 이 타임스탬프는 process mining에서 시간 분석의 기준이 됩니다. 이벤트를 시간순으로 정렬하고 활동 간 소요 시간을 계산하며 주기 시간을 측정하고 시간에 따른 프로세스 성과를 분석하는 데 사용합니다.
중요한 이유
이 속성은 이벤트의 시간순 흐름을 제공하며, 시간 기반 지표를 계산하고 프로세스 흐름을 파악하는 데 필요합니다.
확보 방법
이슈의 'created_at', 'updated_at', 'closed_at' 및 merge request의 'merged_at' 등 GitLab의 여러 타임스탬프 필드에서 추출합니다.
예시
2023-10-26T10:00:00Z2023-11-01T14:35:10Z2023-11-15T09:00:00Z
|
|||
|
활동
Activity
|
'이슈 생성'이나 'Merge Request 병합'처럼 발생한 특정 프로세스 단계 또는 이벤트의 이름입니다. | ||
|
설명
활동 속성은 개발 항목에서 발생하는 개별 이벤트를 기록합니다. GitLab의 단일 필드에 저장되는 값이 아니라 Issues, Merge Requests, CI/CD Pipelines의 여러 작업과 타임스탬프 필드에서 도출합니다. 예를 들어 이슈 생성, 커밋 푸시, 파이프라인 실패, merge request 승인 등이 각각 별도의 활동입니다. 이 속성은 프로세스 맵을 만들고 워크플로를 시각화하며 이벤트의 순서와 빈도를 분석하는 데 기본이 됩니다. 편차, 단계 간 병목, 자주 나타나는 프로세스 경로를 찾는 데 활용합니다.
중요한 이유
프로세스 맵의 단계를 정의해 개발 워크플로 전체를 시각화하고 분석할 수 있습니다.
확보 방법
GitLab 이벤트 스트림의 이벤트 유형과 상태 변경에서 도출하거나, Issues 및 Merge Requests의 'created_at', 'merged_at', 'closed_at' 같은 타임스탬프 필드를 해석해 도출합니다.
예시
이슈 생성개발 시작Merge Request 병합파이프라인 실패프로덕션 배포 완료
|
|||
|
개발 항목 유형
DevelopmentItemType
|
'기능', '버그', '작업', '유지보수' 등 개발 항목의 분류입니다. | ||
|
설명
이 속성은 수행하는 작업의 성격을 분류합니다. GitLab에서는 일반적으로 이슈에 라벨을 적용해 관리합니다. 팀은 라벨로 신규 기능, 결함 수정, 기술 부채 등 작업 유형을 구분합니다. 개발 항목 유형별로 분석하면 작업 유형에 따른 프로세스 흐름과 주기 시간을 비교할 수 있습니다. 예를 들어 버그 수정이 기능 개발보다 빠른지, 기술 부채 작업이 다른 검토 절차를 따르는지 분석할 수 있습니다.
중요한 이유
작업 유형별로 프로세스를 나누어 분석하면 특정 유형의 작업에서 지연, 재작업, 편차가 더 자주 발생하는지 확인할 수 있습니다.
확보 방법
일반적으로 GitLab 이슈에 적용된 'labels'에서 도출합니다. 특정 라벨을 표준 유형으로 변환하는 매핑 규칙이 필요합니다.
예시
기능버그작업기술 부채
|
|||
|
담당자
Assignee
|
이벤트 발생 시점에 이슈나 merge request를 담당한 사용자입니다. | ||
|
설명
담당자는 프로세스의 특정 시점에 작업 항목을 맡은 개발자 또는 사용자입니다. GitLab에서는 Issue나 Merge Request의 담당자별 분석은 '개발자 업무량 및 배분' 대시보드에 중요합니다. 리소스 활용 현황을 파악하고 업무가 과중한 개인이나 팀을 찾으며 담당자 간 인계를 분석할 수 있습니다.
중요한 이유
작업을 수행한 사람을 추적해 업무량과 리소스 배분 효율을 분석하고, 인계로 인한 지연을 찾을 수 있습니다.
확보 방법
GitLab Issues 및 Merge Requests API 응답의 'assignee.username' 또는 'assignees' 필드에서 가져옵니다.
예시
jdoeasmithr.williams
|
|||
|
심각도
Severity
|
일반적으로 버그나 인시던트에 적용하는 개발 항목의 심각도 수준입니다. | ||
|
설명
심각도는 버그나 이슈가 미치는 영향을 나타내며, 치명적부터 경미한 수준까지 구분합니다. GitLab에는 기본 심각도 필드가 없으므로 대부분 라벨(예: 'severity::1', 'severity::2')로 관리합니다. 이 속성은 '심각도 에스컬레이션 추세' 대시보드와 관련 KPI에 필요합니다. 수명 주기 동안 심각도가 어떻게 바뀌는지 분석하면 처음에 문제를 과소평가했거나 프로세스가 문제를 악화시킨 사례를 찾을 수 있습니다.
중요한 이유
작업의 우선순위를 정하고 심각도가 높은 항목을 더 빠르게 처리하는지 분석할 수 있습니다. 변경 사항을 추적하면 '심각도 에스컬레이션 빈도' KPI를 측정할 수 있습니다.
확보 방법
GitLab 이슈에 적용된 'labels'에서 도출합니다. 'S1', 'S2' 같은 라벨을 심각도 수준으로 해석하려면 매핑이 필요합니다.
예시
1 - 치명적2 - 높음3 - 보통4 - 낮음
|
|||
|
종료 시각
EndTime
|
활동이나 이벤트가 완료된 시점을 나타내는 타임스탬프입니다. | ||
|
설명
EndTime은 활동이 끝난 날짜와 시각을 정확히 나타냅니다. '이슈 생성'처럼 GitLab의 여러 단일 이벤트에서는 EndTime과 StartTime이 같습니다. '코드 검토'처럼 지속 시간이 있는 활동에서는 최종 승인이 이루어진 시점과 같은 완료 타임스탬프를 나타냅니다. 이 속성은 개별 활동의 소요 시간(처리 시간)을 정확히 계산하는 데 필요합니다. 작업에 실제로 투입된 시간과 작업 사이의 대기 시간을 구분해 병목을 자세히 분석할 수 있습니다.
중요한 이유
활동별 소요 시간(처리 시간)을 정확히 계산해 프로세스에서 비효율적인 단계를 찾을 수 있습니다.
확보 방법
단일 이벤트에서는 StartTime과 같습니다. 지속 시간이 있는 활동은 데이터에서 해당 완료 이벤트를 찾아 도출해야 합니다.
예시
2023-10-26T10:00:00Z2023-11-01T18:00:15Z2023-11-15T11:30:00Z
|
|||
|
프로젝트 이름
ProjectName
|
개발 항목이 속한 GitLab 프로젝트의 이름입니다. | ||
|
설명
이 속성은 작업이 진행되는 코드 저장소나 프로젝트를 식별합니다. GitLab에서는 모든 이슈와 merge request가 프로젝트에 포함됩니다. 프로젝트 이름별로 분석하면 제품, 구성 요소, 서비스 간 성과를 비교할 수 있습니다. 프로젝트별 SDLC 프로세스 상태를 비교하고 관심 영역에 맞게 대시보드를 필터링하는 데 유용합니다.
중요한 이유
제품, 애플리케이션, 구성 요소별로 프로세스를 나누어 분석하고 해당 영역에 맞는 개선을 추진할 수 있습니다.
확보 방법
Project API의 'name' 또는 'path_with_namespace' 필드에서 가져옵니다. Issues 및 Merge Requests의 'project_id'를 사용해 연결합니다.
예시
플랫폼/api-게이트웨이프런트엔드/고객-포털모바일/ios-앱
|
|||
|
Merge Request 상태
MergeRequestStatus
|
이벤트와 연결된 Merge Request의 상태입니다. 예: '열림', '병합됨', '닫힘'. | ||
|
설명
이 속성은 이벤트 발생 시점의 Merge Request(MR) 상태를 기록합니다. GitLab MR의 상태는 '열림', '닫힘', '병합됨', '잠김'으로 구분됩니다. 전체 개발 항목 상태와는 별개의 값입니다. MR 상태를 추적하면 SDLC의 코드 통합 단계를 분석하는 데 도움이 됩니다. '코드 리뷰 주기 시간 및 처리량' 대시보드와 같은 분석을 지원하며, MR 생성부터 검토, 승인, 병합까지 어느 구간에서 지연되는지 파악할 수 있습니다.
중요한 이유
SDLC에서 병목이 되기 쉬운 코드 리뷰 및 병합 과정을 파악할 수 있습니다.
확보 방법
GitLab Merge Requests API 응답의 'state' 필드에서 가져옵니다.
예시
열림병합됨종료잠김
|
|||
|
Pipeline 상태
PipelineStatus
|
CI/CD pipeline 실행 상태입니다. 예: '성공', '실패', '실행 중'. | ||
|
설명
이 속성은 커밋 또는 Merge Request와 연결된 CI/CD pipeline 실행 결과를 나타냅니다. GitLab에서 흔히 사용하는 상태는 '실행 중', '대기 중', '성공', '실패', '취소됨', '건너뜀'입니다. 이 데이터는 '재작업 및 재실행 분석' 대시보드에 필요합니다. Pipeline 실패가 잦으면 재작업과 지연이 늘어날 수 있습니다. 실패 빈도와 발생 지점, 영향을 분석하면 개발 효율과 코드 품질을 개선하는 데 도움이 됩니다.
중요한 이유
자동 빌드와 테스트의 성공 및 실패를 추적해 재작업 반복과 코드 품질 또는 테스트 자동화 문제를 파악합니다.
확보 방법
GitLab CI/CD Pipelines API 응답의 'status' 필드에서 가져옵니다.
예시
성공실패실행 중취소됨
|
|||
|
개발 항목 상태
DevelopmentItemStatus
|
'열림', '진행 중', '종료' 등 이벤트 발생 시점의 개발 항목 상태입니다. | ||
|
설명
이 속성은 기본 작업 항목의 상태를 나타내며, 일반적으로 GitLab의 이슈가 해당합니다. GitLab 이슈에는 'opened' 또는 'closed' 상태가 있습니다. 더 세분화된 상태는 범위가 지정된 라벨(예: 'Status::Triage', 'Status::In-Dev', 'Status::In-Review')로 관리하는 경우가 많습니다. 상태 변경을 추적하면 케이스의 수명 주기를 파악할 수 있습니다. 각 상태에 머문 시간을 확인하고 'SDLC 전체 주기 시간' 대시보드에서 진행 중인 작업과 완료된 작업을 필터링하는 데 활용할 수 있습니다.
중요한 이유
케이스의 현재 상태를 보여주므로 여러 단계에 걸린 시간을 분석하고 진행 중인 작업과 완료된 작업을 구분할 수 있습니다.
확보 방법
기본 상태는 GitLab 이슈의 'state' 필드('opened', 'closed')에서 가져옵니다. 더 세분화된 상태는 라벨에서 도출하는 경우가 많습니다.
예시
열림종료진행 중검토 중
|
|||
|
대상 브랜치
TargetBranch
|
Merge Request를 병합할 대상 브랜치의 이름입니다. | ||
|
설명
대상 브랜치는 변경 사항을 병합하려는 브랜치입니다. 예를 들어 'main', 'develop' 또는 'release/1.5'와 같은 릴리스 브랜치가 있습니다. Merge Request를 분석할 때 필요한 기본 정보입니다. 대상 브랜치별로 분석하면 병합 대상에 따라 프로세스가 어떻게 달라지는지 확인할 수 있습니다. 예를 들어 'main'에 병합할 때는 기능 브랜치에 병합할 때보다 승인 절차가 엄격하고 주기 시간이 길 수 있습니다. 운영 배포와 다른 코드 통합 유형을 구분하는 데도 활용할 수 있습니다.
중요한 이유
대상 브랜치에 따라 프로세스가 크게 달라질 수 있으므로 개발 및 릴리스 워크플로를 구분하는 데 도움이 됩니다.
확보 방법
GitLab Merge Requests API 응답의 'target_branch' 필드에서 가져옵니다.
예시
maindeveloprelease/v2.1.0hotfix/user-auth-bug
|
|||
|
릴리스 버전
ReleaseVersion
|
배포와 연결된 예정 또는 실제 소프트웨어 버전 태그입니다. | ||
|
설명
이 속성은 개발 항목이 속한 소프트웨어 릴리스를 식별합니다. GitLab에서는 마일스톤, 보호된 태그 또는 Releases 기능의 항목을 통해 릴리스와 연결할 수 있습니다. '릴리스 일정 준수 추적' 대시보드에 필요한 정보입니다. 실제 배포일과 릴리스 버전에 연결된 계획일을 비교하면 일정 준수 여부를 측정하고 릴리스 지연의 원인을 파악할 수 있습니다.
중요한 이유
개발 항목을 특정 소프트웨어 릴리스와 연결해 릴리스 진행 상황과 일정 준수 여부를 추적할 수 있습니다.
확보 방법
GitLab Releases, git 태그 이름 또는 릴리스 계획에 사용한 마일스톤 제목에서 가져올 수 있습니다.
예시
v1.2.0v3.0.0-beta2023.4.1
|
|||
|
마일스톤 제목
MilestoneTitle
|
개발 항목이 배정된 마일스톤 또는 스프린트의 제목입니다. | ||
|
설명
GitLab의 마일스톤은 스프린트나 릴리스 버전처럼 특정 목표 또는 기간을 기준으로 작업을 추적하는 데 사용됩니다. 이 속성에는 해당 마일스톤의 이름이나 제목이 기록됩니다. 특정 스프린트나 계획 기간을 기준으로 프로세스 성과를 분석할 수 있습니다. 스프린트가 바뀔 때마다 주기 시간이 개선되는지 확인하거나, 예정된 릴리스와 관련된 작업만 프로세스 화면에 표시할 수 있습니다.
중요한 이유
개발 작업을 스프린트나 릴리스 같은 계획 주기와 연결해, 계획된 기간을 기준으로 성과를 분석할 수 있습니다.
확보 방법
GitLab Issues 또는 Merge Requests API 응답의 'milestone.title' 필드에서 가져옵니다.
예시
2023년 4분기 릴리스스프린트 23.111단계: MVP
|
|||
|
마지막 데이터 업데이트
LastDataUpdate
|
원천 시스템에서 이 이벤트의 데이터를 마지막으로 새로 가져온 시점을 나타내는 타임스탬프입니다. | ||
|
설명
이 속성은 이벤트 데이터가 process mining 데이터셋에 마지막으로 추출되거나 업데이트된 날짜와 시각을 기록합니다. 이벤트가 발생한 시점이 아니라 이벤트 기록이 마지막으로 동기화된 시점을 나타냅니다. 데이터의 최신성을 파악하고 프로세스 분석이 적시에 이루어졌는지 확인하는 데 중요합니다. 대시보드와 KPI가 최신 데이터를 기반으로 하는지 확인할 수 있으며, 원천 시스템과 분석 데이터 간의 지연 가능성도 알 수 있습니다.
중요한 이유
데이터의 최신 상태를 투명하게 보여주어 사용자가 프로세스 분석 데이터가 얼마나 최신인지 확인할 수 있습니다.
확보 방법
데이터를 새로 고칠 때 데이터 추출 도구나 ETL 프로세스가 생성하고 기록하는 타임스탬프입니다.
예시
2024-05-21T02:00:00Z2024-05-22T02:00:00Z
|
|||
|
원천 시스템
SourceSystem
|
데이터를 가져온 시스템을 식별합니다. | ||
|
설명
이 속성은 프로세스 데이터의 출처를 나타냅니다. 이 데이터 모델에서는 값이 항상 'GitLab'입니다. Jira에서 계획 데이터를, GitLab에서 실행 데이터를 가져오는 것처럼 여러 시스템의 프로세스 데이터를 결합하는 환경에서는 이 속성이 중요합니다. 데이터를 필터링하고 구분할 수 있으며 데이터 계보를 관리하는 데도 도움이 됩니다.
중요한 이유
데이터 출처를 명확히 해 데이터 거버넌스를 지원하고 여러 기업 시스템의 데이터를 통합할 때 유용합니다.
확보 방법
데이터 변환 과정에서 추가하는 고정값 'GitLab'입니다.
예시
GitLab
|
|||
|
인계 대기 시간
HandoffWaitTime
|
담당자가 다른 두 연속 활동 사이의 유휴 시간입니다. | ||
|
설명
담당자가 바뀌는 경우 한 활동이 끝난 시점부터 다음 활동이 시작될 때까지의 간격을 계산합니다. 예를 들어 개발자가 작업을 마친 시점부터 검토자가 코드 리뷰를 시작할 때까지 걸린 시간을 측정합니다. '평균 인계 대기 시간' KPI의 주요 지표입니다. 리소스 배분이나 팀 간 또는 개인 간 소통에서 발생하는 숨은 비효율을 찾아, 실제 작업이 진행되지 않는 동안의 지연을 파악할 수 있습니다.
중요한 이유
사람이나 팀 간 업무 인계 중 발생하는 유휴 시간을 수치화해 숨은 지연과 소통 병목을 드러냅니다.
확보 방법
process mining 도구가 계산합니다. 케이스 내 연속 이벤트를 분석해 '담당자'가 바뀌었는지 확인한 다음 시간 차이를 계산합니다.
예시
1일 2시간15분8시간
|
|||
|
재작업 여부
IsRework
|
활동이 재작업 반복 과정에 포함되는지 나타내는 불리언 플래그입니다. | ||
|
설명
이 계산 속성은 테스트가 시작된 뒤 개발 단계로 돌아가는 경우처럼 프로세스가 이전 단계로 되돌아가는 활동을 표시합니다. 일반적으로 같은 케이스에서 'Pipeline 실패' 또는 'QA 테스트 시작' 이벤트 이후에 '개발 시작' 이벤트가 발생하는지 확인하는 방식으로 판별합니다. 이 속성은 '재작업 및 재실행 분석' 대시보드와 '테스트 후 재작업률' KPI에 사용됩니다. 재작업을 쉽게 필터링하고 수치화해 빈도와 원인, 프로젝트 일정에 미치는 영향을 파악할 수 있습니다.
중요한 이유
재작업을 직접 표시하고 수치화해 프로세스 비효율과 품질 문제의 원인 및 영향을 분석할 수 있습니다.
확보 방법
process mining 도구가 케이스별 활동 순서를 분석하고 재작업을 나타내는 패턴을 찾아 계산합니다.
예시
truefalse
|
|||
|
주기 시간
CycleTime
|
개발 항목의 첫 활동부터 마지막 활동까지 걸린 총시간입니다. | ||
|
설명
주기 시간은 케이스의 전체 소요 시간을 측정하는 계산 지표입니다. 일반적으로 하나의 개발 항목에서 첫 이벤트(예: '이슈 생성')와 마지막 이벤트(예: '운영 환경에 배포') 사이의 시간 차이로 계산합니다. 프로세스 전반의 효율을 측정하는 주요 KPI입니다. 'SDLC 전체 주기 시간' 대시보드의 주요 지표로, 개선 상황을 추적하고 시스템 문제를 나타낼 수 있는 장기 실행 케이스를 찾는 데 사용합니다.
중요한 이유
개발 수명 주기 전반의 효율을 측정하는 process mining의 주요 KPI입니다.
확보 방법
process mining 도구가 고유한 CaseId별로 StartTime의 최댓값에서 최솟값을 빼서 계산합니다.
예시
10일 4시간23시간 15분35일
|
|||
|
팀 이름
TeamName
|
프로젝트 또는 담당자와 연결된 개발팀입니다. | ||
|
설명
팀 이름은 개발 항목을 담당하는 그룹이나 스쿼드를 나타냅니다. 일반적으로 GitLab의 기본 필드가 아니며, 프로젝트 명명 규칙이나 그룹 구조를 활용하거나 외부 참조 테이블에서 담당자를 해당 팀에 연결해 도출합니다. 이 속성은 팀별 프로세스 성과를 분석하는 데 사용합니다. 팀마다 효율성, 업무량, 프로세스 준수 수준을 비교할 수 있으며, 팀별 관점에서 '단계별 병목 분석' 대시보드를 지원합니다.
중요한 이유
팀별 성과와 프로세스를 비교해 특정 팀의 병목이나 모범 사례를 찾을 수 있습니다.
확보 방법
GitLab 외부에서 정의한 팀 구조에 프로젝트 이름이나 담당자를 연결하거나, GitLab 그룹 계층을 바탕으로 도출하는 경우가 많습니다.
예시
프런트엔드-알파백엔드-서비스플랫폼-인프라
|
|||
소프트웨어 개발 수명 주기 활동
| 활동 | 설명 | ||
|---|---|---|---|
|
Merge Request 병합
|
코드 검토와 통합이 성공적으로 완료된 시점을 나타냅니다. 사용자가 merge request의 브랜치를 대상 브랜치에 병합할 때 발생하는 명시적 이벤트입니다. | ||
|
중요한 이유
개발과 검토가 완료되었음을 나타내는 주요 이정표입니다. 개발 주기 시간을 측정하는 종료 시점이자 배포 리드 타임 측정의 시작 시점입니다.
확보 방법
'merge_requests' 테이블의 'merged_at' 타임스탬프에서 확인할 수 있는 명시적 이벤트입니다. 병합 시 시스템 노트도 생성됩니다.
기록
merge request의 'merged_at' 타임스탬프를 사용합니다.
이벤트 유형
explicit
|
|||
|
Merge Request 생성
|
초기 개발 작업이 끝나 코드 검토와 통합을 진행할 준비가 되었음을 나타냅니다. 개발자가 새 merge request(MR)를 열 때 기록되는 GitLab 워크플로의 주요 명시적 이벤트입니다. | ||
|
중요한 이유
개발에서 검토와 테스트로 넘어가는 시점을 나타내는 주요 이정표입니다. 전체 코드 검토 및 CI/CD 파이프라인 주기를 분석하는 출발점으로 활용할 수 있습니다.
확보 방법
'merge_requests' 테이블의 'created_at' 타임스탬프 또는 Merge Requests API에서 확인할 수 있는 명시적 이벤트입니다.
기록
merge request의 'created_at' 타임스탬프를 사용합니다.
이벤트 유형
explicit
|
|||
|
이슈 생성
|
이 활동은 개발 수명 주기의 시작을 나타내며, 기능, 버그, 작업과 같은 새 작업 항목이 생성된 시점을 뜻합니다. 사용자가 GitLab에서 새 이슈를 만들면 생성 시각이 기록되어 명시적으로 확인할 수 있습니다. | ||
|
중요한 이유
이는 전체 프로세스의 주요 시작 이벤트입니다. 이슈 생성부터 배포까지 걸리는 시간을 분석하면 SDLC 주기 시간을 전체적으로 파악할 수 있습니다.
확보 방법
'issues' 테이블의 'created_at' 타임스탬프 또는 Issues API에서 확인할 수 있는 명시적 이벤트입니다. 시스템 노트에도 생성 이벤트가 기록됩니다.
기록
이슈의 'created_at' 타임스탬프를 사용합니다.
이벤트 유형
explicit
|
|||
|
프로덕션 배포 완료
|
코드가 실제 프로덕션 환경에 성공적으로 배포되어 최종 사용자에게 제공된 시점을 나타냅니다. GitLab CI/CD 파이프라인에서 'deploy to production' 작업이 성공적으로 완료되면 기록됩니다. | ||
|
중요한 이유
이는 프로세스의 주요 종료 이벤트로, 가치가 전달된 시점을 나타냅니다. 전체 SDLC 주기 시간과 릴리스 빈도를 측정하는 데 필요합니다.
확보 방법
프로덕션 배포용으로 지정된 CI/CD 작업이 성공적으로 완료된 시점의 'finished_at' 타임스탬프에서 확인할 수 있습니다. GitLab의 Environments 기능에 명시적으로 기록됩니다.
기록
프로덕션 배포에 성공한 CI 작업의 'finished_at' 타임스탬프를 사용합니다.
이벤트 유형
explicit
|
|||
|
개발 시작
|
이 활동은 이슈에 대한 실제 코딩 작업이 시작된 시점을 나타냅니다. GitLab에는 명시적인 '개발 시작' 버튼이 없으므로, 일반적으로 이슈와 연결된 브랜치에 첫 코드 커밋이 푸시된 시점으로 추정합니다. | ||
|
중요한 이유
가치를 창출하는 개발 작업이 실제로 시작된 시점을 파악할 수 있습니다. 이를 통해 순수 코딩 단계의 시간을 정확히 측정하고 계획이나 대기 시간을 분리할 수 있습니다.
확보 방법
이슈와 연결된 기능 브랜치의 첫 커밋 타임스탬프로 추정합니다. 이슈와 브랜치를 연결해야 하며, 일반적으로 명명 규칙이나 메타데이터를 활용합니다.
기록
이슈 ID와 연결된 브랜치에서 첫 커밋의 타임스탬프를 찾습니다.
이벤트 유형
inferred
|
|||
|
배포 시작
|
스테이징이나 프로덕션과 같은 특정 환경에 코드를 배포하는 절차가 시작된 시점을 나타냅니다. GitLab에서는 CI/CD 파이프라인의 'deploy' 작업이 시작되는 시점에 해당합니다. | ||
|
중요한 이유
배포 시작 시점을 추적하면 배포 단계에 걸리는 시간을 분리해 측정할 수 있습니다. 배포 리드 타임을 측정하고 최적화하는 데 중요합니다.
확보 방법
배포 작업으로 설정된 CI/CD 작업의 'started_at' 타임스탬프에서 확인할 수 있습니다. 이 정보는 GitLab의 Environments 및 Deployments 기능에 포함됩니다.
기록
배포 작업에 해당하는 CI 작업 로그의 'started_at' 타임스탬프를 사용합니다.
이벤트 유형
explicit
|
|||
|
승인 추가
|
검토자가 merge request의 코드 변경 사항을 공식 승인한 시점을 나타냅니다. 사용자가 'Approve' 버튼을 클릭하면 GitLab에 명시적 이벤트로 기록됩니다. | ||
|
중요한 이유
승인은 중요한 품질 관리 단계입니다. 승인 내역을 추적하면 필수 승인을 받는 데 걸리는 시간을 분석하고 검토 정책의 규정 준수 여부를 확인할 수 있습니다.
확보 방법
merge request 승인 이벤트에서 확인할 수 있습니다. Approvals API를 사용하거나 MR 기록에서 확인할 수 있습니다.
기록
merge request 승인 이벤트 로그의 타임스탬프를 사용합니다.
이벤트 유형
explicit
|
|||
|
이슈 담당자 지정
|
이슈를 특정 개발자나 팀에 할당해 작업 담당자가 정해진 시점을 나타냅니다. GitLab은 이슈의 담당자 필드에 값이 입력되거나 변경될 때마다 이를 명시적 이벤트로 기록합니다. | ||
|
중요한 이유
담당자 지정 내역을 추적하면 리소스 배분, 팀 업무량, 인계 시간을 분석할 수 있습니다. 작업이 생성된 시점부터 담당자가 배정될 때까지의 지연도 파악할 수 있습니다.
확보 방법
이슈의 시스템 노트에서 확인할 수 있습니다. 시스템 노트에는 'assignee'가 추가되거나 변경된 시점이 기록되며, 이벤트 타임스탬프도 포함됩니다.
기록
이슈의 시스템 노트에서 'assignee changed' 이벤트를 추출합니다.
이벤트 유형
explicit
|
|||
|
이슈 종료
|
일반적으로 변경 사항을 배포하고 검증한 뒤 작업 항목을 최종적으로 행정 처리하는 시점을 나타냅니다. 사용자가 GitLab에서 이슈를 닫을 때 명시적 이벤트로 기록됩니다. | ||
|
중요한 이유
이슈를 닫으면 관련 작업이 모두 끝난 것으로 보는 경우가 많습니다. 이슈 종료 시점과 배포 시점을 비교하면 배포 후 검증이나 행정 처리 과정의 지연을 파악할 수 있습니다.
확보 방법
'issues' 테이블의 'closed_at' 타임스탬프 또는 해당 시스템 노트에서 확인할 수 있는 명시적 이벤트입니다.
기록
이슈의 'closed_at' 타임스탬프를 사용합니다.
이벤트 유형
explicit
|
|||
|
코드 검토 시작
|
merge request의 동료 검토가 시작된 시점을 나타냅니다. 작성자가 아닌 사용자가 처음 댓글을 달거나 스레드를 게시하는 등, 검토와 관련된 첫 작업을 기준으로 추정합니다. | ||
|
중요한 이유
MR 생성부터 검토 시작까지 걸리는 시간을 측정하면 대기 지연을 확인할 수 있습니다. 이 대기 시간을 줄이는 것이 전체 코드 검토 주기를 단축하는 데 중요합니다.
확보 방법
MR 작성자가 아닌 사용자가 merge request에 처음 댓글을 달거나 검토 스레드를 게시한 시점으로 추정합니다. 이 데이터는 시스템 노트나 Notes API에서 확인할 수 있습니다.
기록
MR 작성자가 아닌 사용자가 남긴 첫 댓글의 타임스탬프를 찾습니다.
이벤트 유형
inferred
|
|||
|
파이프라인 시작
|
빌드, 테스트, 보안 검사를 수행하는 자동화된 CI/CD 파이프라인이 시작된 시점을 나타냅니다. GitLab은 커밋이나 MR 생성 등으로 파이프라인이 실행될 때 시작 타임스탬프가 포함된 파이프라인 레코드를 명시적으로 생성합니다. | ||
|
중요한 이유
파이프라인 실행을 추적하면 자동화된 테스트와 통합 프로세스의 상태 및 효율성을 확인할 수 있습니다. 자동 검증에 걸리는 시간도 파악할 수 있습니다.
확보 방법
'ci_pipelines' 테이블의 파이프라인 레코드에 있는 'created_at' 또는 'started_at' 타임스탬프나 Pipelines API에서 확인할 수 있습니다.
기록
MR 브랜치와 연결된 파이프라인 실행 레코드의 타임스탬프를 사용합니다.
이벤트 유형
explicit
|
|||
|
파이프라인 실패
|
빌드 오류나 테스트 실패 등 CI/CD 파이프라인의 어느 단계에서든 실행이 실패하면 발생하는 활동입니다. GitLab은 모든 파이프라인의 최종 상태를 명시적으로 기록하므로 실패를 쉽게 확인할 수 있습니다. | ||
|
중요한 이유
파이프라인 실패는 재작업의 주요 원인입니다. 실패 빈도와 지속 시간, 원인을 분석하면 품질 문제, 불안정한 테스트, 개발자에게 피드백이 전달되는 과정의 병목을 찾을 수 있습니다.
확보 방법
'ci_pipelines' 테이블의 파이프라인 레코드에서 상태가 'failed'인 경우로 확인합니다. 'finished_at' 타임스탬프는 실패가 발생한 시점을 나타냅니다.
기록
상태가 'failed'인 파이프라인 레코드를 필터링하고 'finished_at' 타임스탬프를 사용합니다.
이벤트 유형
explicit
|
|||
데이터 추출 가이드
시작할 준비가 되셨나요?
이 템플릿으로 데이터를 준비하고 소프트웨어 개발 수명 주기 최적화를 시작하세요. 지금 프로세스 개선에 착수하세요.
소프트웨어 개발 수명 주기를 개선하세요. 지금 최적화를 시작하세요
SDLC 병목을 해소하고 주기 시간을 30% 단축하며 품질을 높이세요.
신용카드 없이 바로 최적화를 시작할 수 있습니다.