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
- 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
Thuộc tính vòng đời phát triển phần mềm
| 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 Đâ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 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 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
|
|||
Hoạt động trong vòng đời phát triển phần mềm
| 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
|
|||
Hướng dẫn trích xuất dữ liệu
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.
Không cần thẻ tín dụng. Bắt đầu tối ưu ngay.