Mẫu dữ liệu vòng đời phát triển phần mềm

GitLab
Mẫu dữ liệu vòng đời phát triển phần mềm

Mẫu dữ liệu vòng đời phát triển phần mềm

Mẫu này hướng dẫn bạn chuẩn bị các dữ liệu thiết yếu để phân tích quy trình vòng đời phát triển phần mềm. Mẫu nêu rõ những thuộc tính cần thu thập, các hoạt động chính cần theo dõi và cách lấy thông tin trực tiếp từ GitLab. Nhờ tài nguyên này, bạn có thể chuẩn bị dữ liệu để phân tích process mining một cách tự tin.
  • Các thuộc tính nên thu thập
  • Các hoạt động chính cần theo dõi
  • Hướng dẫn trích xuất dữ liệu
Chưa quen với nhật ký sự kiện? Tìm hiểu cách tạo nhật ký sự kiện cho process mining.

Thuộc tính vòng đời phát triển phần mềm

Đây là các trường dữ liệu nên có trong nhật ký sự kiện để phân tích và tối ưu vòng đời phát triển phần mềm.
3 Bắt buộc 5 Nên có 12 Không bắt buộc
Tên Mô tả
Hạng mục phát triển
DevelopmentItem
Mã định danh duy nhất của một đơn vị công việc, chẳng hạn như tính năng, bản sửa lỗi hoặc tác vụ. Mã này dùng làm mã định danh chính cho case.
Mô tả

Hạng mục phát triển là một phần công việc riêng lẻ có thể theo dõi trong suốt vòng đời phát triển phần mềm. Hạng mục này liên kết mọi hoạt động liên quan, từ lúc tạo đến khi triển khai cuối cùng, thành một case thống nhất. Trong GitLab, hạng mục thường được xác định bằng ID nội bộ (IID) của Issue, duy nhất trong từng dự án.

Phân tích theo hạng mục phát triển giúp đo thời gian chu kỳ từ đầu đến cuối, xác định điểm nghẽn và kiểm tra mức độ tuân thủ quy trình. Đây là cơ sở để hiểu công việc được đưa từ ý tưởng đến production hiệu quả ra sao.

Vì sao điều này quan trọng

Đây là mã định danh case thiết yếu, liên kết mọi sự kiện trong quy trình để bạn có thể theo dõi toàn bộ vòng đời của từng hạng mục công việc.

Lấy dữ liệu ở đâu

Thông thường, đây là ID nội bộ (IID) của GitLab Issue. Bạn có thể tìm thấy ID này trong phản hồi Issues API ở trường 'iid'.

Ví dụ
1024512PRJ-2345
Hoạt động
Activity
Tên của bước hoặc sự kiện cụ thể trong quy trình, chẳng hạn như 'Tạo issue' hoặc 'Merge request được hợp nhất'.
Mô tả

Thuộc tính Hoạt động ghi nhận các sự kiện riêng lẻ xảy ra với một hạng mục phát triển. GitLab không lưu các sự kiện này trong một trường duy nhất. Thay vào đó, chúng được tổng hợp từ nhiều hành động và trường dấu thời gian trong Issues, Merge Requests và CI/CD Pipelines. Ví dụ: tạo issue, đẩy commit, pipeline thất bại hoặc phê duyệt merge request đều là những hoạt động riêng biệt.

Thuộc tính này là nền tảng để tạo sơ đồ quy trình, trực quan hóa workflow và phân tích trình tự cũng như tần suất sự kiện. Thuộc tính giúp xác định sai lệch, điểm nghẽn giữa các bước và những luồng quy trình phổ biến.

Vì sao điều này quan trọng

Thuộc tính này xác định các bước trên sơ đồ quy trình, giúp trực quan hóa và phân tích workflow phát triển từ đầu đến cuối.

Lấy dữ liệu ở đâu

Được tổng hợp từ loại sự kiện và thay đổi trạng thái trong luồng sự kiện của GitLab, hoặc từ việc diễn giải các trường dấu thời gian như 'created_at', 'merged_at' và 'closed_at' trên Issues và Merge Requests.

Ví dụ
Tạo issueBắt đầu phát triểnMerge request được hợp nhấtPipeline thất bạiTriển khai lên production
Thời gian bắt đầu
StartTime
Dấu thời gian cho biết một hoạt động hoặc sự kiện bắt đầu khi nào.
Mô tả

StartTime ghi lại chính xác ngày giờ một hoạt động cụ thể diễn ra. Trong GitLab, thông tin này được lưu ở nhiều trường dấu thời gian khác nhau. Ví dụ, StartTime của hoạt động 'Tạo issue' là dấu thời gian created_at của issue, còn StartTime của hoạt động 'Merge request được hợp nhất' là dấu thời gian merged_at của merge request.

Đây là yếu tố thời gian cốt lõi trong process mining. Thuộc tính này giúp sắp xếp sự kiện theo trình tự thời gian, tính khoảng thời gian giữa các hoạt động, đo thời gian chu kỳ và phân tích hiệu quả quy trình theo thời gian.

Vì sao điều này quan trọng

Thuộc tính này cung cấp trình tự sự kiện theo thời gian, cần thiết để tính mọi chỉ số dựa trên thời gian và hiểu luồng quy trình.

Lấy dữ liệu ở đâu

Được trích xuất từ nhiều trường dấu thời gian trong GitLab, chẳng hạn như 'created_at', 'updated_at', 'closed_at' trên issue và 'merged_at' trên merge request.

Ví dụ
2023-10-26T10:00:00Z2023-11-01T14:35:10Z2023-11-15T09:00:00Z
Loại hạng mục phát triển
DevelopmentItemType
Phân loại hạng mục phát triển, chẳng hạn như 'Tính năng', 'Lỗi', 'Tác vụ' hoặc 'Bảo trì'.
Mô tả

Thuộc tính này phân loại công việc đang thực hiện. Trong GitLab, nhóm thường dùng nhãn trên issue để phân biệt tính năng mới, sửa lỗi, nợ kỹ thuật và các loại công việc khác.

Phân tích theo loại hạng mục phát triển giúp so sánh luồng quy trình và thời gian chu kỳ của từng loại công việc. Ví dụ, bạn có thể xem lỗi được xử lý nhanh hơn thời gian phát triển tính năng hay không, hoặc tác vụ xử lý nợ kỹ thuật có theo quy trình xem xét khác không.

Vì sao điều này quan trọng

Phân nhóm quy trình theo loại công việc giúp xác định loại nào dễ bị chậm trễ, phải làm lại hoặc đi chệch quy trình hơn.

Lấy dữ liệu ở đâu

Thường được suy ra từ các 'labels' gắn với GitLab Issue. Cần có quy tắc ánh xạ để chuyển các nhãn cụ thể thành loại tiêu chuẩn.

Ví dụ
Tính năngLỗiNhiệm vụNợ kỹ thuật
Mức độ nghiêm trọng
Severity
Mức độ nghiêm trọng của hạng mục phát triển, thường áp dụng cho lỗi hoặc sự cố.
Mô tả

Mức độ nghiêm trọng cho biết tác động của lỗi hoặc vấn đề, từ nghiêm trọng đến nhẹ. GitLab không có trường mức độ nghiêm trọng mặc định, vì vậy thông tin này hầu như luôn được ghi bằng nhãn, chẳng hạn như 'severity::1', 'severity::2'.

Thuộc tính này cần thiết cho dashboard 'Xu hướng chuyển cấp theo mức độ nghiêm trọng' và KPI liên quan. Phân tích thay đổi về mức độ nghiêm trọng trong suốt vòng đời có thể cho thấy vấn đề ban đầu bị đánh giá thấp hoặc quy trình khiến vấn đề trở nên nghiêm trọng hơn.

Vì sao điều này quan trọng

Giúp ưu tiên công việc và phân tích xem các hạng mục nghiêm trọng có được xử lý nhanh hơn không. Theo dõi thay đổi giúp tính KPI 'Tần suất chuyển cấp theo mức độ nghiêm trọng'.

Lấy dữ liệu ở đâu

Được suy ra từ các 'labels' gắn với GitLab Issue. Cần có quy tắc ánh xạ để diễn giải các nhãn như 'S1', 'S2' thành mức độ nghiêm trọng.

Ví dụ
1 - Nghiêm trọng2 - Cao3 - Trung bình4 - Thấp
Người được giao
Assignee
Người dùng được giao issue hoặc merge request tại thời điểm xảy ra sự kiện.
Mô tả

Người được giao là nhà phát triển hoặc người dùng chịu trách nhiệm cho hạng mục công việc tại một thời điểm trong quy trình. Trong GitLab, thông tin này được lưu ở trường assignee hoặc assignees của Issue hoặc Merge Request.

Phân tích theo người được giao rất quan trọng đối với dashboard 'Khối lượng và phân bổ công việc của nhà phát triển'. Việc này giúp bạn hiểu cách sử dụng tài nguyên, xác định cá nhân hoặc nhóm đang quá tải và phân tích việc bàn giao giữa mọi người.

Vì sao điều này quan trọng

Theo dõi người thực hiện công việc, giúp phân tích khối lượng công việc, hiệu quả phân bổ tài nguyên và độ trễ do bàn giao.

Lấy dữ liệu ở đâu

Lấy từ các trường 'assignee.username' hoặc 'assignees' trong phản hồi của GitLab Issues API và Merge Requests API.

Ví dụ
jdoeasmithr.williams
Tên dự án
ProjectName
Tên dự án GitLab chứa hạng mục phát triển.
Mô tả

Thuộc tính này xác định kho mã nguồn hoặc dự án cụ thể nơi công việc được thực hiện. Trong GitLab, mỗi issue và merge request đều thuộc về một dự án.

Phân tích theo Tên dự án giúp so sánh hiệu quả giữa các sản phẩm, thành phần hoặc dịch vụ. Bạn có thể xác định dự án nào có quy trình SDLC hiệu quả hơn và lọc dashboard theo khu vực cần xem.

Vì sao điều này quan trọng

Cho phép phân nhóm phân tích quy trình theo sản phẩm, ứng dụng hoặc thành phần, giúp tập trung cải tiến đúng khu vực.

Lấy dữ liệu ở đâu

Lấy từ các trường 'name' hoặc 'path_with_namespace' trong Project API, liên kết qua 'project_id' trong Issues và Merge Requests.

Ví dụ
platform/api-gatewayfrontend/customer-portalmobile/ios-app
Thời gian kết thúc
EndTime
Dấu thời gian cho biết một hoạt động hoặc sự kiện hoàn tất khi nào.
Mô tả

EndTime ghi lại chính xác ngày giờ một hoạt động kết thúc. Với nhiều sự kiện đơn lẻ trong GitLab, chẳng hạn như 'Tạo issue', EndTime trùng với StartTime. Với hoạt động có thời lượng, chẳng hạn như 'Xem xét mã nguồn', EndTime là thời điểm hoàn tất, ví dụ lúc nhận được phê duyệt cuối cùng.

Thuộc tính này cần thiết để tính chính xác thời lượng của từng hoạt động (thời gian xử lý). Thuộc tính hỗ trợ phân tích điểm nghẽn chi tiết bằng cách phân biệt thời gian thực sự làm việc với thời gian chờ giữa các tác vụ.

Vì sao điều này quan trọng

Giúp tính chính xác thời lượng hoạt động (thời gian xử lý), yếu tố then chốt để xác định các bước kém hiệu quả trong quy trình.

Lấy dữ liệu ở đâu

Với sự kiện đơn lẻ, giá trị này trùng với StartTime. Với hoạt động có thời lượng, cần suy ra giá trị bằng cách tìm sự kiện hoàn tất tương ứng trong dữ liệu.

Ví dụ
2023-10-26T10:00:00Z2023-11-01T18:00:15Z2023-11-15T11:30:00Z
Có phải làm lại
IsRework
Cờ đúng/sai cho biết một hoạt động có thuộc vòng lặp làm lại hay không.
Mô tả

Thuộc tính được tính này đánh dấu các hoạt động cho thấy quy trình phải quay lại bước trước, chẳng hạn như quay lại phát triển sau khi đã bắt đầu kiểm thử. Thông thường, cờ này được xác định bằng cách phát hiện các chuỗi hoạt động cụ thể. Ví dụ: sự kiện 'Bắt đầu phát triển' xảy ra sau sự kiện 'Pipeline thất bại' hoặc 'Bắt đầu kiểm thử QA' trong cùng một trường hợp.

Thuộc tính này hỗ trợ trực tiếp bảng điều khiển 'Phân tích làm lại và chạy lại' cùng KPI 'Tỷ lệ làm lại sau kiểm thử'. Nhờ đó, bạn có thể dễ dàng lọc và định lượng công việc làm lại, giúp nhóm hiểu tần suất, nguyên nhân và tác động của việc này đến tiến độ dự án.

Vì sao điều này quan trọng

Đánh dấu và định lượng trực tiếp công việc làm lại, giúp bạn dễ phân tích nguyên nhân và tác động của sự kém hiệu quả trong quy trình cũng như các vấn đề về chất lượng.

Lấy dữ liệu ở đâu

Công cụ process mining tính chỉ số này bằng cách phân tích chuỗi hoạt động của từng trường hợp và tìm các mẫu cho thấy có công việc làm lại.

Ví dụ
truefalse
Hệ thống nguồn
SourceSystem
Xác định hệ thống cung cấp dữ liệu.
Mô tả

Thuộc tính này cho biết nguồn gốc của dữ liệu quy trình. Trong mô hình dữ liệu này, giá trị luôn là 'GitLab'.

Thuộc tính này rất cần thiết trong môi trường kết hợp dữ liệu quy trình từ nhiều hệ thống, chẳng hạn như Jira để lập kế hoạch và GitLab để thực thi. Thuộc tính giúp lọc, phân nhóm và theo dõi nguồn gốc dữ liệu.

Vì sao điều này quan trọng

Làm rõ nguồn gốc dữ liệu, yếu tố quan trọng trong quản trị dữ liệu và khi tích hợp dữ liệu từ nhiều hệ thống doanh nghiệp.

Lấy dữ liệu ở đâu

Đây là giá trị tĩnh 'GitLab', được thêm trong quá trình chuyển đổi dữ liệu.

Ví dụ
GitLab
Lần cập nhật dữ liệu gần nhất
LastDataUpdate
Dấu thời gian cho biết lần gần nhất dữ liệu của sự kiện được làm mới từ hệ thống nguồn.
Mô tả

Thuộc tính này ghi lại ngày giờ dữ liệu sự kiện được trích xuất hoặc cập nhật lần gần nhất trong tập dữ liệu process mining. Thuộc tính không cho biết thời điểm sự kiện xảy ra, mà cho biết lần gần nhất bản ghi sự kiện được đồng bộ.

Thông tin này rất quan trọng để hiểu dữ liệu còn mới đến đâu và xác minh mức độ cập nhật của phân tích quy trình. Nhờ đó, người dùng biết dashboard và KPI dựa trên dữ liệu gần đây hay không, đồng thời nắm được độ trễ có thể có giữa hệ thống nguồn và phần phân tích.

Vì sao điều này quan trọng

Cho biết dữ liệu được cập nhật đến đâu, giúp người dùng nắm rõ mức độ mới của kết quả phân tích quy trình.

Lấy dữ liệu ở đâu

Dấu thời gian này được công cụ trích xuất dữ liệu hoặc quy trình ETL tạo và ghi lại mỗi khi làm mới dữ liệu.

Ví dụ
2024-05-21T02:00:00Z2024-05-22T02:00:00Z
Nhánh đích
TargetBranch
Tên nhánh đích mà Merge Request sẽ được hợp nhất vào.
Mô tả

Nhánh đích là nhánh sẽ nhận các thay đổi sau khi hợp nhất, chẳng hạn như 'main', 'develop' hoặc nhánh phát hành như 'release/1.5'. Đây là thông tin cốt lõi của mọi Merge Request.

Phân tích theo nhánh đích có thể cho thấy quy trình xử lý mã khác nhau tùy nơi hợp nhất. Ví dụ, các thay đổi hợp nhất vào 'main' có thể cần quy trình phê duyệt chặt chẽ hơn và thời gian chu kỳ dài hơn so với nhánh tính năng. Thông tin này cũng giúp phân biệt các lần triển khai lên môi trường production với những hình thức tích hợp mã khác.

Vì sao điều này quan trọng

Giúp phân biệt các quy trình phát triển và phát hành, vì cách xử lý có thể khác đáng kể tùy theo nhánh đích.

Lấy dữ liệu ở đâu

Lấy từ trường 'target_branch' trong phản hồi của GitLab Merge Requests API.

Ví dụ
maindeveloprelease/v2.1.0hotfix/user-auth-bug
Phiên bản phát hành
ReleaseVersion
Thẻ phiên bản phần mềm dự kiến hoặc thực tế gắn với lần triển khai.
Mô tả

Thuộc tính này xác định phiên bản phần mềm cụ thể mà một mục phát triển thuộc về. Trong GitLab, thông tin này có thể được liên kết qua Milestone, thẻ được bảo vệ hoặc mục trong tính năng Releases.

Đây là dữ liệu thiết yếu cho bảng điều khiển 'Theo dõi mức độ tuân thủ lịch phát hành'. Bằng cách so sánh ngày triển khai thực tế với ngày dự kiến gắn với phiên bản phát hành, tổ chức có thể đo lường khả năng đáp ứng lịch trình và tìm nguyên nhân khiến đợt phát hành chậm trễ.

Vì sao điều này quan trọng

Liên kết các mục phát triển với một phiên bản phần mềm cụ thể, giúp theo dõi tiến độ và mức độ tuân thủ lịch phát hành.

Lấy dữ liệu ở đâu

Có thể lấy thông tin này từ GitLab Releases, tên git tag hoặc tiêu đề Milestone dùng để lập kế hoạch phát hành.

Ví dụ
v1.2.0v3.0.0-beta2023.4.1
Tên nhóm
TeamName
Nhóm phát triển phụ trách dự án hoặc người được giao.
Mô tả

Tên nhóm cho biết nhóm hoặc đội phụ trách hạng mục phát triển. GitLab thường không có trường tiêu chuẩn cho thông tin này. Thông tin thường được suy ra từ quy ước đặt tên dự án, cấu trúc nhóm hoặc bảng tham chiếu bên ngoài dùng để liên kết người được giao với nhóm tương ứng.

Thuộc tính này dùng để phân tích hiệu quả quy trình ở cấp nhóm. Bạn có thể so sánh hiệu quả, khối lượng công việc và mức độ tuân thủ quy trình giữa các nhóm. Thuộc tính cũng hỗ trợ các dashboard như 'Phân tích điểm nghẽn theo giai đoạn' theo góc nhìn nhóm.

Vì sao điều này quan trọng

Cho phép phân tích hiệu quả và so sánh quy trình giữa các nhóm, giúp xác định điểm nghẽn riêng của từng nhóm hoặc cách làm hiệu quả.

Lấy dữ liệu ở đâu

Thường được suy ra bằng cách liên kết Tên dự án hoặc Người được giao với cơ cấu nhóm được xác định bên ngoài GitLab, hoặc dựa trên hệ thống phân cấp nhóm trong GitLab.

Ví dụ
Frontend-AlphaBackend-ServicesPlatform-Infra
Thời gian chờ bàn giao
HandoffWaitTime
Thời gian nhàn rỗi được tính giữa hai hoạt động liên tiếp do những người được giao việc khác nhau thực hiện.
Mô tả

Chỉ số này đo khoảng thời gian từ lúc một hoạt động hoàn tất đến khi hoạt động tiếp theo bắt đầu, cụ thể là khi người được giao việc thay đổi. Ví dụ, chỉ số đo thời gian từ lúc lập trình viên hoàn tất công việc đến khi người đánh giá bắt đầu xem xét mã.

Đây là chỉ số chính của KPI 'Thời gian chờ bàn giao trung bình'. Chỉ số giúp phát hiện những điểm kém hiệu quả khó thấy trong việc phân bổ nguồn lực và giao tiếp giữa các nhóm hoặc cá nhân, đồng thời làm rõ thời gian chậm trễ không thuộc bất kỳ hoạt động nào đang diễn ra.

Vì sao điều này quan trọng

Định lượng thời gian nhàn rỗi khi bàn giao giữa người hoặc nhóm, giúp phát hiện độ trễ tiềm ẩn và điểm nghẽn trong giao tiếp.

Lấy dữ liệu ở đâu

Công cụ process mining tính chỉ số này bằng cách phân tích các sự kiện liên tiếp trong một trường hợp, kiểm tra xem 'Assignee' có thay đổi hay không, rồi tính khoảng thời gian chênh lệch.

Ví dụ
1 ngày 2 giờ15 phút8 giờ
Thời gian chu kỳ
CycleTime
Tổng thời gian từ hoạt động đầu tiên đến hoạt động cuối cùng của một mục phát triển.
Mô tả

Thời gian chu kỳ là chỉ số được tính để đo tổng thời lượng của một trường hợp. Thông thường, chỉ số này được tính bằng khoảng thời gian từ sự kiện đầu tiên (ví dụ: 'Tạo issue') đến sự kiện cuối cùng (ví dụ: 'Triển khai lên production') của một mục phát triển.

Đây là KPI chính để đo hiệu quả tổng thể của quy trình. Chỉ số này đóng vai trò trọng tâm trong các bảng điều khiển như 'Thời gian chu kỳ SDLC từ đầu đến cuối', đồng thời giúp theo dõi cải tiến và xác định các trường hợp kéo dài có thể báo hiệu vấn đề mang tính hệ thống.

Vì sao điều này quan trọng

Đây là KPI cốt lõi của process mining, dùng để đo hiệu quả từ đầu đến cuối của vòng đời phát triển.

Lấy dữ liệu ở đâu

Công cụ process mining tính chỉ số này bằng cách lấy StartTime lớn nhất trừ StartTime nhỏ nhất cho từng CaseId duy nhất.

Ví dụ
10 ngày 4 giờ23 giờ 15 phút35 ngày
Tiêu đề mốc
MilestoneTitle
Tiêu đề của mốc hoặc sprint được gán cho mục phát triển.
Mô tả

Trong GitLab, Milestone giúp theo dõi công việc theo một mục tiêu hoặc khoảng thời gian cụ thể, chẳng hạn như sprint hay phiên bản phát hành. Thuộc tính này ghi lại tên hoặc tiêu đề của Milestone đó.

Thuộc tính này giúp phân tích hiệu quả quy trình trong từng sprint hoặc giai đoạn lập kế hoạch. Bạn có thể dùng để xem thời gian chu kỳ có cải thiện qua từng sprint hay không, hoặc lọc chế độ xem quy trình để chỉ hiển thị công việc liên quan đến đợt phát hành sắp tới.

Vì sao điều này quan trọng

Liên kết công việc phát triển với các chu kỳ lập kế hoạch như sprint hoặc đợt phát hành, giúp phân tích hiệu quả so với khoảng thời gian đã định.

Lấy dữ liệu ở đâu

Lấy từ trường 'milestone.title' trong phản hồi của GitLab Issues API hoặc Merge Requests API.

Ví dụ
Phát hành quý 4 năm 2023Sprint 23.11Giai đoạn 1: MVP
Trạng thái hạng mục phát triển
DevelopmentItemStatus
Trạng thái của hạng mục phát triển tại thời điểm xảy ra sự kiện, chẳng hạn như 'Đang mở', 'Đang thực hiện' hoặc 'Đã đóng'.
Mô tả

Thuộc tính này thể hiện trạng thái của hạng mục công việc chính, thường là Issue trong GitLab. GitLab Issue có trường state với giá trị 'opened' hoặc 'closed'. Nhóm thường dùng nhãn có phạm vi để theo dõi trạng thái chi tiết hơn, chẳng hạn như 'Status::Triage', 'Status::In-Dev', 'Status::In-Review'.

Theo dõi thay đổi trạng thái là việc cần thiết để hiểu vòng đời của case. Thuộc tính này giúp xác định mỗi hạng mục ở từng trạng thái trong bao lâu và lọc công việc đang thực hiện hoặc đã hoàn tất trên các dashboard như 'Thời gian chu kỳ SDLC từ đầu đến cuối'.

Vì sao điều này quan trọng

Cung cấp ảnh chụp trạng thái của case, giúp phân tích thời gian ở từng giai đoạn và lọc công việc đang thực hiện hoặc đã hoàn tất.

Lấy dữ liệu ở đâu

Trạng thái chính lấy từ trường 'state' của GitLab Issue ('opened', 'closed'). Trạng thái chi tiết hơn thường được suy ra từ nhãn.

Ví dụ
Đang mởĐã đóngĐang thực hiệnĐang xem xét
Trạng thái Merge Request
MergeRequestStatus
Trạng thái của Merge Request gắn với sự kiện, chẳng hạn như 'Opened', 'Merged' hoặc 'Closed'.
Mô tả

Thuộc tính này ghi nhận trạng thái của Merge Request (MR) tại thời điểm xảy ra sự kiện. GitLab có các trạng thái MR riêng biệt: 'opened', 'closed', 'merged' hoặc 'locked'. Trạng thái này khác với trạng thái chung của mục phát triển.

Theo dõi trạng thái MR rất quan trọng để phân tích giai đoạn tích hợp mã trong SDLC. Dữ liệu này hỗ trợ trực tiếp các bảng điều khiển như 'Thời gian và thông lượng chu kỳ đánh giá mã', đồng thời giúp xác định độ trễ giữa lúc tạo MR, đánh giá, phê duyệt và hợp nhất.

Vì sao điều này quan trọng

Giúp bạn theo dõi quy trình đánh giá và hợp nhất mã, vốn thường là điểm nghẽn quan trọng trong SDLC.

Lấy dữ liệu ở đâu

Lấy từ trường 'state' trong phản hồi của GitLab Merge Requests API.

Ví dụ
Đang mởđã hợp nhấtĐã đóngđã khóa
Trạng thái pipeline
PipelineStatus
Trạng thái của lần chạy CI/CD pipeline, chẳng hạn như 'Success', 'Failed' hoặc 'Running'.
Mô tả

Thuộc tính này cho biết kết quả thực thi CI/CD pipeline gắn với một commit hoặc Merge Request. Các trạng thái thường gặp trong GitLab gồm 'running', 'pending', 'success', 'failed', 'canceled' và 'skipped'.

Dữ liệu này rất cần thiết cho bảng điều khiển 'Phân tích làm lại và chạy lại'. Pipeline thường xuyên thất bại có thể khiến công việc phải làm lại và gây chậm trễ đáng kể. Phân tích tần suất, vị trí và tác động của các lỗi này là yếu tố then chốt để nâng cao hiệu quả phát triển và chất lượng mã.

Vì sao điều này quan trọng

Theo dõi kết quả thành công và thất bại của các bản dựng và bài kiểm thử tự động, qua đó làm rõ các vòng lặp làm lại và vấn đề về chất lượng mã hoặc tự động hóa kiểm thử.

Lấy dữ liệu ở đâu

Lấy từ trường 'status' trong phản hồi của GitLab CI/CD Pipelines API.

Ví dụ
thành côngthất bạiđang chạyđã hủy
Bắt buộc Nên có Không bắt buộc

Hoạt động trong vòng đời phát triển phần mềm

Đây là các bước quy trình và mốc quan trọng cần ghi lại trong nhật ký sự kiện để khám phá quy trình chính xác và xác định điểm nghẽn.
4 Nên có 8 Không bắt buộc
Hoạt động Mô tả
Merge request được hợp nhất
Hoạt động này đánh dấu việc hoàn tất thành công quá trình xem xét và tích hợp mã nguồn. Sự kiện xảy ra khi người dùng hợp nhất nhánh của merge request vào nhánh đích.
Vì sao điều này quan trọng

Đây là cột mốc quan trọng, cho biết giai đoạn phát triển và xem xét đã hoàn tất. Đây là điểm kết thúc để đo thời gian chu kỳ phát triển và điểm bắt đầu để đo thời gian triển khai.

Lấy dữ liệu ở đâu

Sự kiện được ghi nhận rõ ràng từ dấu thời gian 'merged_at' trong bảng 'merge_requests'. GitLab cũng tạo system note khi hợp nhất.

Thu thập

Dùng dấu thời gian 'merged_at' của merge request.

Loại sự kiện explicit
Tạo issue
Hoạt động này đánh dấu thời điểm bắt đầu vòng đời phát triển, khi một hạng mục công việc mới được tạo, chẳng hạn như tính năng, lỗi hoặc tác vụ. Sự kiện được ghi nhận rõ ràng khi người dùng tạo issue mới trong GitLab, hệ thống sẽ lưu dấu thời gian tạo.
Vì sao điều này quan trọng

Đây là sự kiện bắt đầu chính của quy trình từ đầu đến cuối. Phân tích thời gian từ lúc tạo issue đến khi triển khai giúp bạn nắm được toàn bộ thời gian chu kỳ SDLC.

Lấy dữ liệu ở đâu

Đây là sự kiện được ghi nhận rõ ràng từ dấu thời gian 'created_at' trong bảng 'issues' hoặc qua Issues API. System notes cũng ghi lại sự kiện tạo issue.

Thu thập

Dùng dấu thời gian 'created_at' của issue.

Loại sự kiện explicit
Tạo merge request
Sự kiện này cho biết công việc phát triển ban đầu đã hoàn tất và mã nguồn sẵn sàng để xem xét, tích hợp. Đây là sự kiện cốt lõi được ghi nhận rõ ràng trong workflow GitLab khi nhà phát triển mở merge request (MR) mới.
Vì sao điều này quan trọng

Đây là cột mốc quan trọng, đánh dấu thời điểm bàn giao từ phát triển sang xem xét và kiểm thử. Đây cũng là điểm bắt đầu để phân tích toàn bộ chu kỳ xem xét mã nguồn và pipeline CI/CD.

Lấy dữ liệu ở đâu

Sự kiện được ghi nhận rõ ràng từ dấu thời gian 'created_at' trong bảng 'merge_requests' hoặc qua Merge Requests API.

Thu thập

Dùng dấu thời gian 'created_at' của merge request.

Loại sự kiện explicit
Triển khai lên production
Hoạt động này đánh dấu việc triển khai mã nguồn thành công lên môi trường production đang hoạt động, nơi người dùng cuối có thể sử dụng. Sự kiện được ghi nhận khi công việc 'deploy to production' trong pipeline CI/CD của GitLab hoàn tất thành công.
Vì sao điều này quan trọng

Đây là sự kiện kết thúc chính của quy trình, cho biết giá trị đã được bàn giao. Sự kiện này cần thiết để đo tổng thời gian chu kỳ SDLC từ đầu đến cuối và tần suất phát hành.

Lấy dữ liệu ở đâu

Sự kiện được lấy từ dấu thời gian 'finished_at' của công việc CI/CD triển khai production hoàn tất thành công. Tính năng Environments của GitLab theo dõi rõ ràng sự kiện này.

Thu thập

Dùng dấu thời gian 'finished_at' từ công việc CI triển khai production thành công.

Loại sự kiện explicit
Bắt đầu phát triển
Hoạt động này đánh dấu thời điểm bắt đầu viết mã. Thông thường, thời điểm này được suy ra từ commit đầu tiên được đẩy lên nhánh liên kết với issue, vì GitLab không có nút 'bắt đầu phát triển' riêng.
Vì sao điều này quan trọng

Xác định chính xác lúc công việc phát triển tạo ra giá trị bắt đầu, giúp đo riêng giai đoạn viết mã và phân biệt giai đoạn này với thời gian lập kế hoạch hoặc chờ xử lý.

Lấy dữ liệu ở đâu

Thời điểm này được suy ra từ dấu thời gian của commit đầu tiên trên nhánh tính năng liên kết với issue. Cần liên kết issue với nhánh, thường thông qua quy ước đặt tên hoặc metadata.

Thu thập

Tìm dấu thời gian của commit đầu tiên trên nhánh liên kết với ID issue.

Loại sự kiện inferred
Bắt đầu pipeline
Sự kiện này ghi nhận thời điểm khởi chạy pipeline CI/CD tự động, thường dùng để build, kiểm thử và quét bảo mật. Mỗi khi pipeline được kích hoạt, chẳng hạn bởi một commit hoặc lúc tạo MR, GitLab sẽ tạo bản ghi pipeline có dấu thời gian bắt đầu.
Vì sao điều này quan trọng

Theo dõi các lần chạy pipeline là việc cần thiết để giám sát tình trạng và hiệu quả của quy trình kiểm thử, tích hợp tự động. Việc này giúp xác định thời gian dành cho khâu kiểm tra tự động.

Lấy dữ liệu ở đâu

Sự kiện được lấy từ dấu thời gian 'created_at' hoặc 'started_at' của bản ghi pipeline trong bảng 'ci_pipelines' hoặc qua Pipelines API.

Thu thập

Dùng dấu thời gian trong bản ghi thực thi pipeline liên kết với nhánh của MR.

Loại sự kiện explicit
Bắt đầu triển khai
Sự kiện này đánh dấu thời điểm bắt đầu đưa mã nguồn lên một môi trường cụ thể, chẳng hạn như staging hoặc production. Trong GitLab, đây là lúc một công việc 'deploy' trong pipeline CI/CD bắt đầu.
Vì sao điều này quan trọng

Theo dõi thời điểm bắt đầu triển khai giúp xác định riêng thời lượng của giai đoạn này. Đây là thông tin cần thiết để đo và tối ưu thời gian triển khai.

Lấy dữ liệu ở đâu

Sự kiện được lấy từ dấu thời gian 'started_at' của công việc CI/CD được cấu hình làm công việc triển khai. Đây là một phần trong tính năng Environments and Deployments của GitLab.

Thu thập

Dùng dấu thời gian 'started_at' từ nhật ký công việc CI triển khai.

Loại sự kiện explicit
Bắt đầu xem xét mã nguồn
Sự kiện này đánh dấu thời điểm bắt đầu quá trình đồng nghiệp xem xét merge request. Thời điểm được suy ra từ hành động đầu tiên liên quan đến việc xem xét, chẳng hạn như bình luận hoặc tạo chuỗi thảo luận đầu tiên từ người không phải tác giả.
Vì sao điều này quan trọng

Đo thời gian từ lúc tạo MR đến khi bắt đầu xem xét giúp phát hiện độ trễ do chờ trong hàng đợi. Rút ngắn thời gian chờ này là yếu tố then chốt để giảm tổng thời gian xem xét mã nguồn.

Lấy dữ liệu ở đâu

Thời điểm được suy ra từ dấu thời gian của bình luận hoặc chuỗi thảo luận đầu tiên trên merge request do người không phải tác giả MR đăng. Bạn có thể lấy dữ liệu này qua system notes hoặc Notes API.

Thu thập

Tìm dấu thời gian của bình luận đầu tiên trên MR từ người không phải tác giả.

Loại sự kiện inferred
Đóng issue
Sự kiện này ghi nhận việc đóng hạng mục công việc về mặt hành chính, thường diễn ra sau khi các thay đổi đã được triển khai và xác minh. GitLab ghi nhận rõ ràng sự kiện khi người dùng đóng issue.
Vì sao điều này quan trọng

Đóng issue thường đánh dấu thời điểm kết thúc mọi công việc liên quan. So sánh thời điểm này với thời điểm triển khai có thể giúp phát hiện độ trễ trong khâu xác minh sau triển khai hoặc xử lý hành chính.

Lấy dữ liệu ở đâu

Sự kiện được ghi nhận rõ ràng từ dấu thời gian 'closed_at' trong bảng 'issues' hoặc từ system note tương ứng.

Thu thập

Dùng dấu thời gian 'closed_at' của issue.

Loại sự kiện explicit
Giao issue
Sự kiện này ghi nhận việc giao issue cho một nhà phát triển hoặc nhóm cụ thể, cho biết người chịu trách nhiệm đã được xác định. GitLab ghi lại sự kiện này mỗi khi trường người được giao của issue được điền hoặc thay đổi.
Vì sao điều này quan trọng

Theo dõi việc giao công việc rất quan trọng để phân tích phân bổ tài nguyên, khối lượng công việc của nhóm và thời gian bàn giao. Việc này giúp phát hiện độ trễ giữa lúc tạo công việc và lúc có người bắt đầu xử lý.

Lấy dữ liệu ở đâu

Sự kiện được lấy từ system notes của issue trong GitLab, nơi ghi lại thời điểm thêm hoặc thay đổi 'assignee'. Dấu thời gian sự kiện được lưu trong ghi chú.

Thu thập

Trích xuất các sự kiện 'assignee changed' từ system notes của issue.

Loại sự kiện explicit
Pipeline thất bại
Hoạt động này xảy ra khi pipeline CI/CD thất bại ở bất kỳ giai đoạn nào, chẳng hạn như lỗi build hoặc kiểm thử không đạt. GitLab ghi lại rõ ràng trạng thái cuối của mỗi pipeline nên bạn có thể dễ dàng xác định các lần thất bại.
Vì sao điều này quan trọng

Pipeline thất bại là nguyên nhân chính khiến công việc phải làm lại. Phân tích tần suất, thời lượng và nguyên nhân thất bại giúp phát hiện vấn đề chất lượng, kiểm thử chập chờn và điểm nghẽn trong vòng phản hồi cho nhà phát triển.

Lấy dữ liệu ở đâu

Xác định sự kiện qua trạng thái 'failed' trong bản ghi pipeline ở bảng 'ci_pipelines'. Dấu thời gian 'finished_at' cho biết thời điểm pipeline thất bại.

Thu thập

Lọc các bản ghi pipeline có trạng thái 'failed' và dùng dấu thời gian 'finished_at'.

Loại sự kiện explicit
Thêm phê duyệt
Sự kiện này ghi nhận việc người xem xét chính thức phê duyệt các thay đổi mã nguồn trong merge request. GitLab ghi nhận rõ ràng sự kiện khi người dùng nhấn nút 'Approve'.
Vì sao điều này quan trọng

Phê duyệt là một bước kiểm soát chất lượng quan trọng. Theo dõi bước này giúp phân tích thời gian cần để nhận đủ xác nhận và đảm bảo tuân thủ chính sách xem xét mã nguồn.

Lấy dữ liệu ở đâu

Sự kiện được lấy từ các lần phê duyệt merge request. Bạn có thể truy xuất qua Approvals API hoặc xem trong lịch sử MR.

Thu thập

Dùng dấu thời gian từ nhật ký sự kiện phê duyệt merge request.

Loại sự kiện explicit
Nên có Không bắt buộc

Hướng dẫn trích xuất dữ liệu

Cách lấy dữ liệu từ GitLab

Bạn đã sẵn sàng bắt đầu chưa?

Dùng mẫu này để chuẩn bị dữ liệu và bắt đầu tối ưu vòng đời phát triển phần mềm. Bắt đầu cải tiến quy trình ngay hôm nay!

Cải thiện vòng đời phát triển phần mềm: bắt đầu tối ưu ngay

Loại bỏ điểm nghẽn trong SDLC, giảm 30% thời gian chu kỳ và nâng cao chất lượng.

Bắt đầu dùng thử miễn phí

Không cần thẻ tín dụng. Bắt đầu tối ưu ngay.