เทมเพลตข้อมูลวงจรการพัฒนาซอฟต์แวร์
เทมเพลตข้อมูลวงจรการพัฒนาซอฟต์แวร์
- แอตทริบิวต์ที่แนะนำให้รวบรวม
- กิจกรรมสำคัญที่ควรติดตาม
- แนวทางดึงข้อมูล
แอตทริบิวต์ของวงจรการพัฒนาซอฟต์แวร์
| ชื่อ | คำอธิบาย | ||
|---|---|---|---|
|
กิจกรรม
ActivityName
|
ชื่อเหตุการณ์หรืองานที่เกิดขึ้นในวงจรการพัฒนาซอฟต์แวร์. | ||
|
คำอธิบาย
ชื่อกิจกรรมอธิบายขั้นตอนหนึ่งในกระบวนการพัฒนา เช่น 'สร้าง Issue แล้ว' 'ส่งโค้ดไปยัง PR แล้ว' 'อนุมัติ Pull Request แล้ว' หรือ 'นำไปใช้งานสำเร็จแล้ว' เหตุการณ์เหล่านี้เรียงต่อกันเป็นขั้นตอนของกระบวนการตั้งแต่ต้นจนจบสำหรับรายการพัฒนา คุณลักษณะนี้เป็นพื้นฐานสำคัญของ process mining เพราะใช้สร้างแผนผังกระบวนการ การวิเคราะห์ลำดับ ความถี่ และระยะเวลาของกิจกรรมเหล่านี้ช่วยให้เห็นการไหลของกระบวนการจริง ระบุเส้นทางที่เกิดขึ้นบ่อย ตรวจพบความคลาดเคลื่อน และค้นหาคอขวดได้.
เหตุผลที่สำคัญ
คุณลักษณะนี้เป็นแกนหลักของแผนผังกระบวนการ ช่วยให้เห็นภาพและวิเคราะห์ลำดับเหตุการณ์ในวงจรการพัฒนาได้.
แหล่งข้อมูล
ได้จากฟิลด์ 'action' ในข้อมูลเหตุการณ์ webhook เช่น 'opened' หรือ 'closed' สำหรับ Issue หรือได้จากประเภทเหตุการณ์โดยตรง เช่น 'PushEvent' หรือ 'PullRequestReviewEvent'.
ตัวอย่าง
สร้าง Issueเปิด Pull RequestPush โค้ดไปยัง PRขอให้ตรวจสอบโค้ดรวม Pull Request แล้ว
|
|||
|
รายการพัฒนา
DevelopmentItemId
|
รหัสเฉพาะของงานพัฒนาแต่ละรายการ เช่น ฟีเจอร์ การแก้บั๊ก หรืองานทั่วไป ใช้เป็นรหัสอ้างอิงหลักของแต่ละกรณี. | ||
|
คำอธิบาย
Development Item ID ใช้ติดตามรายการงานตั้งแต่สร้างจนถึงนำขึ้นใช้งานขั้นสุดท้าย โดยเชื่อมกิจกรรมที่เกี่ยวข้องทั้งหมด เช่น การสร้าง Branch, commit, pull request, การตรวจสอบ และ deployment ให้เป็นกระบวนการเดียวกัน ในการวิเคราะห์ จะใช้ ID นี้คำนวณระยะเวลาตั้งแต่ต้นจนจบของงานพัฒนา และสร้างลำดับการทำงานทั้งหมดของฟีเจอร์หรือการแก้บั๊กขึ้นใหม่ เพื่อวิเคราะห์คอขวด การวนกลับไปแก้งาน และความแตกต่างของกระบวนการในแต่ละรายการได้อย่างละเอียด.
เหตุผลที่สำคัญ
รหัสนี้เป็นกุญแจสำคัญของ process mining เพราะเชื่อมเหตุการณ์การพัฒนาที่เกี่ยวข้องทั้งหมดไว้ในกรณีเดียว ช่วยให้เห็นภาพและวิเคราะห์วงจรการพัฒนาซอฟต์แวร์ตั้งแต่ต้นจนจบได้อย่างแม่นยำ.
แหล่งข้อมูล
โดยทั่วไปคือหมายเลข Issue หรือ Pull Request จาก GitHub ซึ่งดึงได้จากฟิลด์ 'number' ในข้อมูลของ webhook หรือผลตอบกลับ API ที่เกี่ยวข้องกับ Issue หรือ pull request.
ตัวอย่าง
101PR-2345TASK-812
|
|||
|
เวลาเริ่มต้น
EventTimestamp
|
วันที่และเวลาที่แน่นอนซึ่งกิจกรรมหรือเหตุการณ์การพัฒนาเกิดขึ้น. | ||
|
คำอธิบาย
เวลาเริ่มต้นนี้ระบุจุดเริ่มของกิจกรรม จำเป็นต่อการเรียงเหตุการณ์ตามลำดับเวลาเพื่อสร้างขั้นตอนการทำงานของรายการพัฒนาแต่ละรายการขึ้นใหม่ ระบบใช้ลำดับและช่วงเวลาระหว่างเวลาเหล่านี้วิเคราะห์ประสิทธิภาพของกระบวนการ ในการวิเคราะห์ คุณลักษณะนี้จำเป็นต่อการคำนวณตัวชี้วัดด้านเวลา ทั้งระยะเวลาของวงจร เวลาที่ใช้ดำเนินงาน และเวลารอ ช่วยระบุความล่าช้าระหว่างขั้นตอน และให้ข้อมูลสำหรับวิเคราะห์คอขวดกับติดตามประสิทธิภาพผ่านแดชบอร์ด.
เหตุผลที่สำคัญ
เวลานี้จำเป็นต่อการเรียงเหตุการณ์ให้ถูกต้องและคำนวณตัวชี้วัดประสิทธิภาพ เช่น ระยะเวลาของวงจรและเวลาที่ใช้ในคอขวด.
แหล่งข้อมูล
โดยทั่วไปพบในฟิลด์ 'created_at' หรือ 'updated_at' ในข้อมูล JSON จาก GitHub API และ webhook ของออบเจ็กต์ต่างๆ เช่น Issue, pull request และ commit.
ตัวอย่าง
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-10-28T09:00:25Z
|
|||
|
Repository
RepositoryName
|
ชื่อ repository ของโค้ดที่ใช้ทำกิจกรรมการพัฒนา. | ||
|
คำอธิบาย
repository ทำหน้าที่ระบุโครงการหรือผลิตภัณฑ์ โดยเก็บโค้ด Issue และ pull request ทั้งหมดของแอปพลิเคชันหรือส่วนประกอบที่กำหนด จึงใช้แบ่งกลุ่มและเปรียบเทียบกระบวนการพัฒนาระหว่างผลิตภัณฑ์หรือทีมต่างๆ ได้ ในการวิเคราะห์ คุณลักษณะนี้ใช้กรองและเปรียบเทียบประสิทธิภาพของกระบวนการระหว่างโครงการ ช่วยตอบคำถาม เช่น 'โครงการใดใช้เวลาตั้งแต่งานเริ่มจนเสร็จนานที่สุด' หรือ 'กระบวนการแก้บั๊กในโครงการ A ต่างจากโครงการ B อย่างไร' และจำเป็นต่อแดชบอร์ด 'ปริมาณงานตามโครงการและประเภท'.
เหตุผลที่สำคัญ
ช่วยแบ่งกลุ่มและเปรียบเทียบกระบวนการพัฒนาระหว่างโครงการ ผลิตภัณฑ์ หรือทีม เพื่อให้วิเคราะห์ได้ตรงจุดยิ่งขึ้น.
แหล่งข้อมูล
มีอยู่ในออบเจ็กต์ 'repository' ในข้อมูล webhook และ API ของ GitHub เกือบทั้งหมด โดยทั่วไปฟิลด์ที่ใช้คือ 'repository.full_name' หรือ 'repository.name'.
ตัวอย่าง
my-org/web-appmy-org/api-servicemy-org/data-pipeline
|
|||
|
ประเภทรายการพัฒนา
DevelopmentItemType
|
การจัดประเภทงานพัฒนา เช่น ฟีเจอร์ บั๊ก งานทั่วไป หรือ epic. | ||
|
คำอธิบาย
คุณลักษณะนี้จัดหมวดหมู่ลักษณะของงานที่ทำ โดยทั่วไปจะจัดการข้อมูลนี้ผ่าน label หรือเทมเพลต Issue เฉพาะใน GitHub การเข้าใจประเภทงานสำคัญต่อการกำหนดความคาดหวังด้านประสิทธิภาพที่เหมาะสม เพราะการแก้บั๊กอาจใช้เวลาสั้นกว่าการพัฒนาฟีเจอร์ใหม่มาก คุณลักษณะนี้ช่วยเปรียบเทียบงานประเภทต่างๆ เช่น วิเคราะห์ว่าการแก้บั๊กใช้เวลาน้อยกว่าการพัฒนาฟีเจอร์ใหม่หรือไม่ หรือทำความเข้าใจการจัดสรรทรัพยากรระหว่างงานลดหนี้ทางเทคนิคกับงานพัฒนาใหม่ และเป็นมิติสำคัญในแดชบอร์ด 'ปริมาณงานตามโครงการและประเภท'.
เหตุผลที่สำคัญ
จัดหมวดหมู่รายการงานเพื่อเปรียบเทียบประสิทธิภาพและวิเคราะห์ว่างานแต่ละประเภท เช่น บั๊กหรือฟีเจอร์ ผ่านกระบวนการอย่างไร.
แหล่งข้อมูล
โดยทั่วไปได้จาก label ของ GitHub ที่กำหนดให้ Issue หรือ pull request โดยต้องใช้รูปแบบการกำหนด label ให้สม่ำเสมอ เช่น 'type:bug' หรือ 'type:feature'.
ตัวอย่าง
บั๊กฟีเจอร์งานหนี้ทางเทคนิค
|
|||
|
ผู้ใช้ที่ได้รับมอบหมาย
Assignee
|
ผู้ใช้หรือนักพัฒนาที่ได้รับมอบหมายให้ดูแลรายการพัฒนาหรืองานเฉพาะ เช่น การตรวจสอบ pull request. | ||
|
คำอธิบาย
คุณลักษณะนี้ระบุผู้รับผิดชอบงานในแต่ละขั้นตอน อาจเป็นผู้ที่ได้รับมอบหมายใน Issue ผู้สร้าง pull request หรือผู้ตรวจสอบที่ได้รับคำขอ การติดตามผู้รับผิดชอบช่วยให้เข้าใจการจัดสรรทรัพยากรและภาระงาน ในการวิเคราะห์ คุณลักษณะนี้ใช้ติดตามภาระงานของนักพัฒนา ระบุคอขวดด้านทรัพยากร และวิเคราะห์ประสิทธิภาพการส่งต่องานระหว่างสมาชิกทีม คุณสามารถกรองแดชบอร์ดตามผู้รับผิดชอบเพื่อประเมินประสิทธิภาพของบุคคลหรือทีม และดูว่ามีการกระจายงานอย่างสมดุลหรือไม่.
เหตุผลที่สำคัญ
จำเป็นต่อการวิเคราะห์ภาระงานของนักพัฒนา ประสิทธิภาพของทีม และการส่งต่องานระหว่างสมาชิกทีม.
แหล่งข้อมูล
ดูได้จากออบเจ็กต์ 'assignee' หรือ 'user' ในข้อมูล JSON ของ Issue, pull request และเหตุการณ์การตรวจสอบจาก GitHub API.
ตัวอย่าง
john.doejane.smithdev-team-lead
|
|||
|
ลำดับความสำคัญ
Priority
|
ระดับความสำคัญที่กำหนดให้รายการพัฒนา เช่น 'สูง', 'ปานกลาง' หรือ 'ต่ำ'. | ||
|
คำอธิบาย
Priority ใช้บอกความเร่งด่วนหรือความสำคัญของรายการงานต่อธุรกิจ ใน GitHub ไม่มีฟิลด์ Priority โดยตรง จึงมักใช้ labels เช่น 'P1-High' และ 'P2-Medium' กำหนดระดับความสำคัญ หากต้องการดึงข้อมูลนี้มาใช้อย่างน่าเชื่อถือ ต้องกำหนดรูปแบบ labels ให้เป็นมาตรฐาน แอตทริบิวต์นี้จำเป็นต่อการวิเคราะห์การไหลของงานตาม Priority ช่วยให้ตรวจสอบได้ว่างานที่มี Priority สูงดำเนินการเร็วกว่างานที่มี Priority ต่ำจริงหรือไม่ และวัดความแตกต่างของ cycle time ตามระดับ Priority ได้ จึงใช้ประเมินประสิทธิผลของกระบวนการจัดลำดับความสำคัญได้.
เหตุผลที่สำคัญ
ช่วยวิเคราะห์ว่างานที่มี Priority สูงดำเนินการเร็วกว่างานที่มี Priority ต่ำหรือไม่ เพื่อประเมินว่ากลยุทธ์การจัดลำดับความสำคัญได้ผลเพียงใด.
แหล่งข้อมูล
ดึงข้อมูลจาก labels ที่กำหนดให้กับ issues หรือ pull requests โดยต้องกำหนดรูปแบบการตั้งชื่อ labels สำหรับ Priority ให้เป็นมาตรฐาน.
ตัวอย่าง
สูงปานกลางต่ำวิกฤต
|
|||
|
เวลาสิ้นสุด
EndTimestamp
|
วันที่และเวลาที่แน่นอนซึ่งกิจกรรมหรือเหตุการณ์การพัฒนาเสร็จสิ้น. | ||
|
คำอธิบาย
เวลาสิ้นสุดระบุว่ากิจกรรมเสร็จเมื่อใด เหตุการณ์ใน GitHub หลายอย่างเกิดขึ้นทันที เช่น 'สร้าง Issue' แต่บางกิจกรรมใช้เวลานานพอที่จะวัดได้ เช่น การทำงานของ CI check เมื่อนำเวลาสิ้นสุดลบด้วยเวลาเริ่มต้น จะได้เวลาที่ใช้ดำเนินกิจกรรม คุณลักษณะนี้ใช้คำนวณตัวชี้วัด 'ProcessingTime' ซึ่งช่วยให้เข้าใจว่ามีการลงแรงทำงานจริงกับงานต่างๆ เช่น การตรวจสอบโค้ดหรือการตรวจสอบอัตโนมัตินานเพียงใด การวิเคราะห์เวลาที่ใช้ดำเนินงานช่วยระบุกิจกรรมที่ไม่มีประสิทธิภาพและใช้เวลามากเกินไป.
เหตุผลที่สำคัญ
ช่วยคำนวณเวลาที่ใช้ดำเนินกิจกรรมได้อย่างแม่นยำ และแยกเวลาทำงานจริงออกจากเวลารอได้.
แหล่งข้อมูล
อาจพบในฟิลด์ 'completed_at' ของออบเจ็กต์ check run หรือคำนวณจากเวลาของเหตุการณ์ถัดไปที่เป็นจุดสิ้นสุดตามลำดับเหตุผล.
ตัวอย่าง
2023-10-26T10:05:15Z2023-10-27T18:00:00Z2023-10-28T09:10:30Z
|
|||
|
Commit Hash
CommitHash
|
รหัสเฉพาะ (SHA) ของ commit โค้ดรายการหนึ่ง. | ||
|
คำอธิบาย
commit hash คือค่า SHA-1 ความยาว 40 อักขระที่ใช้ระบุ commit ใน Git โดยไม่ซ้ำกัน ทำหน้าที่เป็นรหัสถาวรของโค้ดเวอร์ชันหนึ่ง commit แต่ละรายการเป็นหน่วยการเปลี่ยนแปลงพื้นฐานในกระบวนการพัฒนา แม้จะมีรายละเอียดระดับสูง แต่ commit hash ช่วยติดตามย้อนกลับได้อย่างแม่นยำ นักวิเคราะห์สามารถเชื่อมเหตุการณ์ในกระบวนการกับการเปลี่ยนแปลงโค้ดที่เกิดขึ้นจริงได้โดยตรง ซึ่งมีประโยชน์อย่างยิ่งต่อการตรวจสอบ การปฏิบัติตามข้อกำหนด หรือการวิเคราะห์หาสาเหตุของเหตุขัดข้องใน production.
เหตุผลที่สำคัญ
เชื่อมขั้นตอนในกระบวนการกับการเปลี่ยนแปลงโค้ดที่เกิดขึ้นจริงได้อย่างละเอียด ช่วยติดตามย้อนกลับเพื่อการตรวจสอบและแก้ไขข้อบกพร่อง.
แหล่งข้อมูล
ดูได้จาก payload ของ push event ('head_commit.id') หรือผ่าน Commits API สำหรับ pull request หรือ branch.
ตัวอย่าง
a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0f0e9d8c7b6a5f4e3d2c1b0a9f8e7d6c5b4a3f2e1
|
|||
|
Labels
Labels
|
รายการแท็กหรือ labels ที่กำหนดให้ issue หรือ pull request เพื่อจัดหมวดหมู่. | ||
|
คำอธิบาย
Labels ใน GitHub เป็นวิธีเพิ่มข้อมูลกำกับให้ issues และ pull requests ได้อย่างยืดหยุ่น ใช้ระบุ Priority ประเภทงาน องค์ประกอบ ทีม หรือสถานะได้ รายการ labels ทั้งหมดจึงให้บริบทที่หลากหลายแต่ไม่มีโครงสร้างตายตัว แม้จะดึงแอตทริบิวต์เฉพาะอย่าง Priority และ Type จาก labels ได้ แต่การเก็บรายการทั้งหมดไว้ก็มีประโยชน์ต่อการวิเคราะห์เฉพาะกิจและค้นหารูปแบบกระบวนการอื่นๆ นอกจากนี้ยังใช้กรองและแบ่งกลุ่ม case ได้อย่างยืดหยุ่นตามชุด labels ที่ต้องการ.
เหตุผลที่สำคัญ
เป็นแหล่งข้อมูลกำกับที่ยืดหยุ่นและมีรายละเอียด ช่วยจัดหมวดหมู่รายการงานและวิเคราะห์ข้อมูลได้หลากหลายมิติ.
แหล่งข้อมูล
ดูได้จากอาร์เรย์ 'labels' ใน JSON payload ของ issues และ pull requests จาก GitHub API แต่ละรายการในอาร์เรย์เป็นออบเจ็กต์ที่มีฟิลด์ 'name'.
ตัวอย่าง
bug, ui, high-priorityfeature, backend, needs-docstech-debt, refactor
|
|||
|
ชื่อ Branch
BranchName
|
ชื่อ Git branch ที่ใช้แก้ไขโค้ดสำหรับรายการงานพัฒนา. | ||
|
คำอธิบาย
branch คือสายการพัฒนาแยกที่สร้างขึ้นเพื่อทำฟีเจอร์ใหม่หรือแก้ข้อบกพร่อง โดยไม่กระทบโค้ดหลัก ชื่อ branch มักมีข้อมูลที่เป็นประโยชน์ เช่น หมายเลข issue หรือคำอธิบายสั้นๆ ของงาน การวิเคราะห์ชื่อ branch ช่วยให้เข้าใจกลยุทธ์การแยก branch และตรวจสอบการทำตามแนวทางการพัฒนาได้ นอกจากนี้ยังช่วยเชื่อม commit ของโค้ดกับรายการงานพัฒนา ทำให้เห็นภาพกิจกรรมการเขียนโค้ดได้ครบถ้วน.
เหตุผลที่สำคัญ
ให้บริบทของสายการพัฒนาที่เกี่ยวข้อง และช่วยกำหนดแนวทางพร้อมวิเคราะห์กลยุทธ์การแยก branch และรูปแบบการตั้งชื่อ.
แหล่งข้อมูล
ดูได้จากฟิลด์ 'ref' ของ push events หรือจากออบเจ็กต์ 'head' และ 'base' ใน API response ของ pull request.
ตัวอย่าง
feature/PROJ-123-new-loginbugfix/fix-payment-bughotfix/critical-security-patch
|
|||
|
เป็นงานแก้ซ้ำ
IsRework
|
แฟล็กแบบ boolean ที่มีค่า true เมื่อกิจกรรมแสดงถึงการย้อนกลับไปยังขั้นตอนก่อนหน้าในกระบวนการ. | ||
|
คำอธิบาย
กำหนดแฟล็กนี้เป็น true เมื่อรายการงานพัฒนาเคลื่อนย้อนกลับในกระบวนการ เช่น pull request ได้รับผลรีวิว 'Changes Requested' หรือ issue ถูกเปิดอีกครั้งหลังปิดไปแล้ว โดยพิจารณาจากลำดับกิจกรรม แอตทริบิวต์นี้จำเป็นต่อการวัดงานสูญเปล่าและความไม่มีประสิทธิภาพ รองรับแดชบอร์ด 'Rework and Regression Loops' และ KPI 'Rework Rate' โดยตรง นักวิเคราะห์สามารถกรอง 'IsRework = true' เพื่อแยกและตรวจสอบสาเหตุของงานแก้ซ้ำได้.
เหตุผลที่สำคัญ
ระบุกิจกรรมที่เป็นงานแก้ซ้ำอย่างชัดเจน ช่วยวัด แสดงภาพ และวิเคราะห์สาเหตุของความไม่มีประสิทธิภาพในกระบวนการได้ง่าย.
แหล่งข้อมูล
แอตทริบิวต์นี้ได้จากการคำนวณ โดยกำหนดลำดับกระบวนการมาตรฐานก่อน แล้วระบุกิจกรรมที่เบี่ยงเบนด้วยการย้อนกลับไปยังขั้นตอนก่อนหน้าในเชิงตรรกะ.
ตัวอย่าง
truefalse
|
|||
|
ผู้รีวิว
Reviewer
|
ผู้ใช้ที่ได้รับคำขอให้รีวิวโค้ดใน pull request. | ||
|
คำอธิบาย
ผู้รีวิวคือนักพัฒนาหรือสมาชิกทีมที่ได้รับมอบหมายให้ตรวจสอบคุณภาพ ความถูกต้อง และการทำตามมาตรฐานของการเปลี่ยนแปลงโค้ดใน pull request หนึ่งรายการอาจมีผู้รีวิวหลายคน แอตทริบิวต์นี้จำเป็นต่อการวิเคราะห์กระบวนการรีวิวโค้ด ช่วยระบุคอขวดที่เกี่ยวข้องกับผู้รีวิวแต่ละคน ทำความเข้าใจการกระจายภาระงานรีวิว และวัดเวลาที่ผู้รีวิวใช้ตอบรับคำขอ นอกจากนี้ยังเป็นองค์ประกอบสำคัญในการคำนวณ KPI 'Average Code Review Cycle Time'.
เหตุผลที่สำคัญ
ระบุผู้ที่มีส่วนร่วมในกระบวนการตรวจสอบคุณภาพ ช่วยวิเคราะห์ภาระงานรีวิว ความล่าช้า และประสิทธิภาพโดยรวมของการรีวิวโค้ด.
แหล่งข้อมูล
ดูได้จากอาร์เรย์ 'requested_reviewers' หรือออบเจ็กต์ 'user' ของเหตุการณ์รีวิว pull request จาก GitHub API.
ตัวอย่าง
alex.chenmaria.garciasenior-dev-team
|
|||
|
ผู้สร้าง
Author
|
ผู้ใช้ที่สร้าง issue, pull request หรือ commit. | ||
|
คำอธิบาย
ผู้สร้างคือผู้เริ่มต้นสร้างรายการงานในกระบวนการพัฒนา เช่น ผู้สร้าง issue คือผู้รายงานข้อบกพร่องหรือขอฟีเจอร์ ส่วนผู้สร้าง pull request คือนักพัฒนาที่เขียนโค้ด การวิเคราะห์ผู้สร้างช่วยให้เข้าใจที่มาของงาน เช่น การวิเคราะห์ผู้รายงานข้อบกพร่องอาจเผยให้เห็นรูปแบบที่เกี่ยวข้องกับบางทีมหรือบางฟีเจอร์ นอกจากนี้ยังใช้ร่วมกับผู้รับผิดชอบเพื่อวิเคราะห์รูปแบบการส่งต่องานได้.
เหตุผลที่สำคัญ
ระบุผู้เริ่มต้นสร้างรายการงานหรือการเปลี่ยนแปลงโค้ด ช่วยวิเคราะห์ที่มาของงานแก้ซ้ำ รายงานข้อบกพร่อง หรือคำขอฟีเจอร์ได้.
แหล่งข้อมูล
ดูได้จากออบเจ็กต์ 'user' ภายในออบเจ็กต์หลักของ API response สำหรับ issues, pull requests และ commits โดยทั่วไปใช้ฟิลด์ 'user.login'.
ตัวอย่าง
sara.jonesmike.leeautomation-bot
|
|||
|
ระบบต้นทาง
SourceSystem
|
ระบบที่ใช้ดึงข้อมูลกระบวนการพัฒนา. | ||
|
คำอธิบาย
คุณลักษณะนี้ระบุที่มาของข้อมูลเหตุการณ์ สำหรับกระบวนการนี้ ค่าจะเป็น 'GitHub' อย่างสม่ำเสมอ ในสภาพแวดล้อมที่ซับซ้อนขึ้น ซึ่งกิจกรรมการพัฒนากระจายอยู่ในหลายระบบ เช่น Jira สำหรับวางแผน GitHub สำหรับโค้ด และ Jenkins สำหรับ deployment ฟิลด์นี้ใช้แยกแหล่งที่มาของแต่ละเหตุการณ์ ในการวิเคราะห์ ฟิลด์นี้ช่วยตรวจสอบย้อนกลับไปยังแหล่งข้อมูลเพื่อยืนยันความถูกต้องและแก้ปัญหา อีกทั้งยังช่วยวิเคราะห์กระบวนการที่เชื่อมโยงหลายแพลตฟอร์ม โดยระบุบริบทของแต่ละกิจกรรมได้ชัดเจน.
เหตุผลที่สำคัญ
ระบุที่มาของข้อมูล ซึ่งจำเป็นต่อการตรวจสอบความถูกต้องของข้อมูลและวิเคราะห์กระบวนการที่อาจเชื่อมโยงหลายระบบเข้าด้วยกัน.
แหล่งข้อมูล
โดยทั่วไปจะกำหนดค่าแบบคงที่ระหว่างขั้นตอนการดึง แปลง และโหลดข้อมูล (ETL) เพื่อระบุแหล่งที่มาของระเบียน.
ตัวอย่าง
GitHubGitHub Enterprise
|
|||
|
ระยะเวลาวงจรการพัฒนา
DevelopmentCycleTime
|
เวลารวมตั้งแต่สร้างรายการงานพัฒนาจนถึงการนำขึ้นใช้งานหรือปิดรายการในขั้นตอนสุดท้าย. | ||
|
คำอธิบาย
ตัวชี้วัดระดับ case นี้คำนวณจากเวลาที่ต่างกันระหว่างเหตุการณ์แรกสุด เช่น 'Issue Created' กับเหตุการณ์สุดท้าย เช่น 'Deployment Succeeded' หรือ 'Issue Closed' ของรายการงานพัฒนาหนึ่งรายการ นี่คือหนึ่งใน KPI สำคัญที่สุดสำหรับวัดประสิทธิภาพโดยรวมของกระบวนการพัฒนา ใช้กับแดชบอร์ด 'Overall Development Cycle Time' และ KPI 'Average Development Cycle Time' ได้โดยตรง การลดตัวชี้วัดนี้มักเป็นเป้าหมายหลักของการปรับปรุงกระบวนการ.
เหตุผลที่สำคัญ
แสดงระยะเวลาตั้งแต่เริ่มต้นจนส่งมอบรายการงานพัฒนา จึงเป็น KPI สำคัญสำหรับวัดความเร็วและประสิทธิภาพของกระบวนการโดยรวม.
แหล่งข้อมูล
คำนวณในระดับ case โดยนำเวลาของกิจกรรมแรกมาลบออกจากเวลาของกิจกรรมสุดท้าย.
ตัวอย่าง
P5DT6H30MP14DT12HP1DT2H
|
|||
|
เวลารอระหว่างการส่งต่องาน
HandoffWaitingTime
|
เวลาที่รายการงานพัฒนาหยุดรอระหว่างกิจกรรมที่ดำเนินการโดยคนละคน ซึ่งคำนวณจากข้อมูลกิจกรรม. | ||
|
คำอธิบาย
ตัวชี้วัดนี้วัดเวลาตั้งแต่กิจกรรมหนึ่งเสร็จจนกิจกรรมถัดไปเริ่ม โดยนับเฉพาะกรณีที่ผู้รับผิดชอบเปลี่ยนคน เช่น เวลาระหว่างเหตุการณ์ 'Review Requested' กับ 'Changes Requested in Review' ที่ดำเนินการโดยผู้ใช้คนละคน ตัวชี้วัดนี้สำคัญต่อการระบุช่องว่างในการสื่อสารและปัญหาการประสานงาน รองรับแดชบอร์ด 'Critical Handoff Efficiency' และ KPI 'Average Handoff Waiting Time' หากมีเวลารอสูงระหว่างการส่งต่องาน มักบ่งชี้ว่าทรัพยากรมีไม่เพียงพอ หรือกระบวนการแจ้งเตือนไม่มีประสิทธิภาพ.
เหตุผลที่สำคัญ
ช่วยระบุความล่าช้าที่เกิดจากการประสานงานไม่ดีหรือไม่มีทรัพยากรพร้อมระหว่างการส่งต่องานข้ามทีมหรือบทบาท ซึ่งมักเป็นสาเหตุสำคัญของความไม่มีประสิทธิภาพ.
แหล่งข้อมูล
คำนวณโดยระบุกิจกรรมที่เกิดเรียงต่อกันและมีการเปลี่ยนแปลงแอตทริบิวต์ 'Assignee' หรือ 'User' จากนั้นวัดช่วงเวลาระหว่างกิจกรรมเหล่านั้น.
ตัวอย่าง
PT1H15MP2DT4HPT25M
|
|||
|
สถานะการตรวจสอบ CI
CiCheckStatus
|
สถานะของการตรวจสอบ Continuous Integration (CI) อัตโนมัติ เช่น 'ผ่าน' หรือ 'ไม่ผ่าน'. | ||
|
คำอธิบาย
แอตทริบิวต์นี้แสดงผลการ build, test และ scan อัตโนมัติที่ทำกับการเปลี่ยนแปลงโค้ดใน pull request การตรวจสอบ CI เป็นจุดตรวจสอบคุณภาพที่สำคัญในเวิร์กโฟลว์การพัฒนาสมัยใหม่ การวิเคราะห์แอตทริบิวต์นี้ช่วยให้เข้าใจประสิทธิผลของการทดสอบอัตโนมัติ หากการตรวจสอบไม่ผ่านบ่อย อาจบ่งชี้ปัญหาด้านเสถียรภาพของโค้ด ชุดทดสอบ หรือสภาพแวดล้อมการพัฒนา ข้อมูลนี้รองรับกิจกรรม 'CI Checks Passed' และ 'CI Checks Failed' และช่วยวิเคราะห์ความล่าช้าที่เกิดจาก build ที่ไม่ผ่าน.
เหตุผลที่สำคัญ
แสดงผลผ่านหรือไม่ผ่านของจุดตรวจสอบคุณภาพอัตโนมัติ ช่วยให้เห็นคุณภาพโค้ดและประสิทธิผลของ CI pipeline.
แหล่งข้อมูล
ดึงข้อมูลจากฟิลด์ 'state' หรือ 'conclusion' ของออบเจ็กต์ check run หรือ status ผ่าน GitHub Checks API หรือ Statuses API.
ตัวอย่าง
successfailurependingerror
|
|||
|
สถานะการรีวิว
ReviewState
|
ผลการรีวิวโค้ดใน pull request เช่น 'Approved' หรือ 'Changes Requested'. | ||
|
คำอธิบาย
แอตทริบิวต์นี้บันทึกการตัดสินใจของผู้รีวิว สถานะที่พบบ่อย ได้แก่ 'APPROVED' หมายถึงโค้ดพร้อม merge และ 'CHANGES_REQUESTED' หมายถึงต้องแก้ไขเพิ่มเติม สถานะอื่นอาจเป็น 'COMMENTED' หรือ 'PENDING' แอตทริบิวต์นี้สำคัญต่อการวิเคราะห์งานแก้ซ้ำและคุณภาพ หากพบเหตุการณ์ 'CHANGES_REQUESTED' บ่อย อาจบ่งชี้ว่าคุณภาพโค้ดตั้งแต่แรกยังไม่ดีพอ หรือข้อกำหนดยังไม่ชัดเจน ข้อมูลนี้ช่วยให้แดชบอร์ด 'Rework and Regression Loops' ระบุได้ว่ารายการงานพัฒนาถูกส่งกลับไปแก้ไขเมื่อใด.
เหตุผลที่สำคัญ
แสดงวงจรการแก้ซ้ำและจุดตรวจสอบคุณภาพในกระบวนการรีวิวโค้ดโดยตรง ช่วยระบุที่มาของความไม่มีประสิทธิภาพและปัญหาด้านคุณภาพ.
แหล่งข้อมูล
ดูได้จากฟิลด์ 'state' ในออบเจ็กต์รีวิว pull request จาก GitHub API เช่น ใน payload ของ 'PullRequestReviewEvent'.
ตัวอย่าง
APPROVEDCHANGES_REQUESTEDCOMMENTED
|
|||
|
สถานะรายการ
State
|
สถานะปัจจุบันของ Issue หรือ pull request เช่น 'open', 'closed' หรือ 'merged'. | ||
|
คำอธิบาย
คุณลักษณะนี้ระบุสถานะโดยรวมของรายการพัฒนา โดย Issue มักมีสถานะ 'open' และ 'closed' ส่วน pull request มีสถานะ 'open', 'closed' และ 'merged' จึงช่วยให้เห็นความคืบหน้าของรายการ ณ เวลานั้น ในการวิเคราะห์ สถานะช่วยแยกงานที่กำลังดำเนินการออกจากงานที่เสร็จแล้ว และจำเป็นต่อแดชบอร์ดอย่าง 'ความคืบหน้าการพัฒนาที่กำลังดำเนินอยู่' ซึ่งใช้ติดตามงานที่ยังไม่เสร็จ นอกจากนี้ยังใช้กำหนดจุดสิ้นสุดของกระบวนการได้ เช่น สถานะ 'merged' หรือ 'closed' อาจหมายถึงกรณีนั้นเสร็จสมบูรณ์แล้ว.
เหตุผลที่สำคัญ
แสดงชัดเจนว่ารายการงานกำลังดำเนินการหรือเสร็จแล้ว ซึ่งเป็นข้อมูลพื้นฐานสำหรับวิเคราะห์วงจรและติดตามงานที่กำลังทำอยู่.
แหล่งข้อมูล
ดูได้โดยตรงจากฟิลด์ 'state' ในข้อมูล JSON ของ Issue และ pull request จาก GitHub API.
ตัวอย่าง
เปิดอยู่ปิดแล้วรวมแล้ว
|
|||
|
สภาพแวดล้อมการนำขึ้นใช้งาน
DeploymentEnvironment
|
สภาพแวดล้อมเป้าหมายสำหรับการนำขึ้นใช้งาน เช่น 'Staging' หรือ 'Production'. | ||
|
คำอธิบาย
แอตทริบิวต์นี้ระบุว่าจะนำโค้ดขึ้นใช้งานที่ใด การติดตามการนำขึ้นใช้งานในสภาพแวดล้อมต่างๆ ช่วยให้เข้าใจวงจรทั้งหมด ตั้งแต่การพัฒนาไปจนถึงการเผยแพร่สู่ production ข้อมูลนี้ใช้วิเคราะห์กระบวนการย่อยด้านการนำขึ้นใช้งาน วัดเวลาที่ใช้ในการเลื่อนโค้ดจาก staging ไป production และติดตามอัตราความสำเร็จของการนำขึ้นใช้งานในแต่ละสภาพแวดล้อมได้ อีกทั้งยังช่วยระบุได้ว่ารายการงานพัฒนาเสร็จสมบูรณ์และส่งถึงผู้ใช้เมื่อใด.
เหตุผลที่สำคัญ
แยกการเผยแพร่ก่อน production ออกจากการเผยแพร่สู่ production ซึ่งสำคัญต่อการวัดระยะเวลาตั้งแต่เริ่มพัฒนาจนถึงตลาดจริง และวิเคราะห์รูปแบบการนำขึ้นใช้งาน.
แหล่งข้อมูล
ดึงข้อมูลนี้จาก GitHub Deployments API ซึ่งมักถูกเรียกใช้โดย CI/CD pipeline หรือระบบอัตโนมัติอื่นๆ.
ตัวอย่าง
developmentstagingproduction
|
|||
|
หมายเลข Pull Request
PullRequestNumber
|
รหัสเฉพาะของ pull request ที่เกี่ยวข้องกับรายการงานพัฒนา. | ||
|
คำอธิบาย
pull request (PR) คือข้อเสนอสำหรับรวมชุดการเปลี่ยนแปลงโค้ดเข้ากับ branch ที่ระบุ หมายเลข Pull Request ใช้เชื่อมกิจกรรมการพัฒนา เช่น การ push โค้ดและการรีวิว กลับไปยังรายการงานหลักหรือ issue รหัสนี้สำคัญต่อการติดตามการรวมโค้ดและกระบวนการย่อยด้านการรีวิวภายในวงจรการพัฒนาโดยรวม ช่วยวิเคราะห์กระบวนการรีวิวโค้ดได้อย่างละเอียด ทั้งระยะเวลารีวิว การแก้ไขซ้ำที่พบระหว่างรีวิว และอัตราการ merge อีกทั้งยังเชื่อมขั้นตอนวางแผน (issue) กับขั้นตอนลงมือพัฒนา (PR) ได้.
เหตุผลที่สำคัญ
เชื่อม issues กับการเปลี่ยนแปลงโค้ดและกระบวนการรีวิวที่เกี่ยวข้อง ช่วยวิเคราะห์วงจรการรีวิวโค้ดและผลต่อเวลาส่งมอบโดยรวมได้อย่างละเอียด.
แหล่งข้อมูล
ดูได้จากฟิลด์ 'number' ในออบเจ็กต์ 'pull_request' ของ GitHub API response หลายรายการ หรือใช้รหัสหลักจาก Pull Requests API.
ตัวอย่าง
12345678910
|
|||
|
อัปเดตข้อมูลล่าสุด
LastDataUpdate
|
เวลาที่ระบุว่าข้อมูลของระเบียนนี้ได้รับการอัปเดตจากระบบต้นทางครั้งล่าสุดเมื่อใด. | ||
|
คำอธิบาย
คุณลักษณะนี้บันทึกวันที่และเวลาที่ดึงหรืออัปเดตข้อมูลครั้งล่าสุด เป็นข้อมูลกำกับที่บอกว่าข้อมูลที่นำมาวิเคราะห์เป็นข้อมูลใหม่เพียงใด ซึ่งต่างจากเวลาของเหตุการณ์ที่บันทึกว่าเหตุการณ์ทางธุรกิจเกิดขึ้นเมื่อใด ในการวิเคราะห์ ฟิลด์นี้สำคัญต่อการดูว่าข้อมูลกระบวนการเป็นปัจจุบันแค่ไหน ช่วยให้ผู้ใช้ทราบว่ากำลังดูข้อมูลแบบเรียลไทม์หรือข้อมูล ณ เวลาใดเวลาหนึ่ง ซึ่งจำเป็นต่อแดชบอร์ดและการติดตามการปฏิบัติการ.
เหตุผลที่สำคัญ
ระบุความใหม่ของข้อมูล ซึ่งจำเป็นต่อการทำให้มั่นใจว่าการวิเคราะห์และแดชบอร์ดอ้างอิงข้อมูลล่าสุด.
แหล่งข้อมูล
ระบบสร้างและเพิ่มเวลานี้ระหว่างขั้นตอนการดึง แปลง และโหลดข้อมูล (ETL).
ตัวอย่าง
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
|
|||
กิจกรรมในวงจรการพัฒนาซอฟต์แวร์
| กิจกรรม | คำอธิบาย | ||
|---|---|---|---|
|
CI Checks ผ่าน
|
แสดงว่าการตรวจสอบอัตโนมัติ เช่น การ build การทดสอบหน่วย หรือการวิเคราะห์โค้ดแบบ static ที่ทำกับโค้ดใน pull request เสร็จสมบูรณ์และผ่าน ระบบอนุมานเหตุการณ์นี้จากสถานะการตรวจสอบที่รายงานโดยระบบอย่าง GitHub Actions. | ||
|
เหตุผลที่สำคัญ
จุดควบคุมคุณภาพอัตโนมัตินี้สำคัญต่อการรักษาเสถียรภาพของโค้ด หากการตรวจสอบไม่ผ่านหรือใช้เวลานาน ก็อาจกลายเป็นคอขวดสำคัญในขั้นตอนส่งมอบ.
แหล่งข้อมูล
อนุมานจาก GitHub Checks API หรือ Statuses API เมื่อ check run หรือการอัปเดตสถานะแจ้งว่า 'success' หรือ 'completed' พร้อมผลสรุป 'success'.
บันทึก
ติดตาม Checks API เพื่อดูผลสรุป 'success' ของชุดการตรวจสอบที่เกี่ยวข้อง.
ประเภทเหตุการณ์
inferred
|
|||
|
ปิด Issue
|
ถือว่ารายการพัฒนาเสร็จสมบูรณ์และปิด Issue ที่เกี่ยวข้องอย่างเป็นทางการ ระบบอาจปิดโดยอัตโนมัติเมื่อรวม pull request ที่เชื่อมโยงแล้ว หรือสมาชิกทีมอาจปิดด้วยตนเอง. | ||
|
เหตุผลที่สำคัญ
กิจกรรมนี้เป็นจุดสิ้นสุดที่ชัดเจนของกระบวนการสำหรับรายการพัฒนา และจำเป็นต่อการคำนวณระยะเวลาตั้งแต่ต้นจนจบ.
แหล่งข้อมูล
เหตุการณ์นี้บันทึกโดยตรงจากสตรีมเหตุการณ์ของ GitHub Issues API โดยประเภทเหตุการณ์คือ 'closed'.
บันทึก
รับฟังเหตุการณ์ 'closed' ของ Issue ผ่าน webhook หรือการเรียก API เป็นระยะ.
ประเภทเหตุการณ์
explicit
|
|||
|
เปิด Pull Request
|
แสดงว่าโค้ดชุดแรกพร้อมให้ตรวจสอบและนำไปรวมแล้ว นักพัฒนาสร้าง pull request (PR) เพื่อเสนอการเปลี่ยนแปลงจาก feature branch ไปยัง Branch หลัก เหตุการณ์นี้บันทึกโดยตรงใน GitHub. | ||
|
เหตุผลที่สำคัญ
นี่คือหมุดหมายสำคัญที่บอกว่าช่วงพัฒนาเริ่มต้นสิ้นสุดลง และเริ่มเข้าสู่ขั้นตอนตรวจสอบและรวมโค้ด การแยกวิเคราะห์ระยะเวลาพัฒนาออกจากระยะเวลาตรวจสอบจึงต้องอาศัยเหตุการณ์นี้.
แหล่งข้อมูล
บันทึกจากสตรีมเหตุการณ์ของ GitHub Pull Request API หรือ webhook โดย action ของเหตุการณ์คือ 'opened'.
บันทึก
รับฟัง action 'opened' ของ pull request ผ่าน webhook หรือการเรียก API เป็นระยะ.
ประเภทเหตุการณ์
explicit
|
|||
|
รวม Pull Request แล้ว
|
นำการเปลี่ยนแปลงโค้ดที่อนุมัติจาก pull request ไปรวมใน Branch เป้าหมาย เช่น main หรือ develop อย่างเป็นทางการ เหตุการณ์นี้เป็นการดำเนินการขั้นสุดท้ายของ pull request ที่นำโค้ดใหม่เข้ามา. | ||
|
เหตุผลที่สำคัญ
นี่คือหมุดหมายสำคัญที่แสดงว่าการพัฒนาและการตรวจสอบเสร็จสิ้นแล้ว สำหรับหลายทีม นี่คือขั้นตอนสุดท้ายก่อนการนำระบบขึ้นใช้งานโดยอัตโนมัติ.
แหล่งข้อมูล
บันทึกจากสตรีมเหตุการณ์ของ GitHub Pull Request API หรือ webhook โดย action คือ 'closed' และค่า 'merged' ในข้อมูล pull request เป็น true.
บันทึก
รับฟัง action 'closed' ของ pull request แล้วตรวจสอบว่า flag 'merged' เป็น true หรือไม่.
ประเภทเหตุการณ์
explicit
|
|||
|
สร้าง Issue
|
เป็นจุดเริ่มต้นของวงจรรายการพัฒนา โดยบันทึกการสร้างงาน บั๊ก หรือคำขอฟีเจอร์อย่างเป็นทางการ ระบบจะบันทึกเหตุการณ์นี้เมื่อผู้ใช้สร้าง Issue ใหม่ใน repository ของ GitHub. | ||
|
เหตุผลที่สำคัญ
กิจกรรมนี้เป็นจุดเริ่มต้นหลักของกระบวนการ จำเป็นต่อการวัดระยะเวลาการพัฒนาทั้งหมดและทำความเข้าใจที่มาของงานในช่วงแรก.
แหล่งข้อมูล
เหตุการณ์นี้บันทึกโดยตรงจากสตรีมเหตุการณ์ของ GitHub Issues API โดยประเภทเหตุการณ์สำหรับหมายเลข Issue ที่ระบุโดยทั่วไปคือ 'opened'.
บันทึก
รับฟังเหตุการณ์ 'opened' ของ Issue ผ่าน webhook หรือการเรียก API เป็นระยะ.
ประเภทเหตุการณ์
explicit
|
|||
|
อนุมัติ Pull Request
|
ผู้ตรวจสอบอนุมัติการเปลี่ยนแปลงใน pull request อย่างเป็นทางการ แสดงว่าโค้ดผ่านมาตรฐานด้านคุณภาพและการทำงาน ระบบบันทึกเหตุการณ์นี้เมื่อผู้ตรวจสอบส่งผลตรวจด้วยสถานะ 'approve'. | ||
|
เหตุผลที่สำคัญ
นี่คือจุดควบคุมคุณภาพสำคัญและหมุดหมายหลักก่อนรวมโค้ด ระยะเวลาตั้งแต่สร้าง PR จนถึงสถานะนี้เป็น KPI สำคัญในการวัดประสิทธิภาพของขั้นตอนตรวจสอบ.
แหล่งข้อมูล
บันทึกจาก GitHub Pull Request API หรือ webhook เมื่อส่งผลตรวจสอบด้วยสถานะ 'APPROVED'.
บันทึก
กรองเหตุการณ์ส่งผลตรวจสอบ pull request โดยเลือกสถานะ 'APPROVED'.
ประเภทเหตุการณ์
explicit
|
|||
|
CI Checks ไม่ผ่าน
|
แสดงว่าการตรวจสอบอัตโนมัติ เช่น การ build เกิดข้อผิดพลาดหรือการทดสอบหน่วยไม่ผ่าน เมื่อทำกับโค้ดใน pull request ระบบอนุมานเหตุการณ์นี้จากสถานะไม่ผ่านที่รายงานโดยระบบอย่าง GitHub Actions. | ||
|
เหตุผลที่สำคัญ
กิจกรรมนี้ชี้ให้เห็นปัญหาคุณภาพทางเทคนิคที่ต้องให้นักพัฒนาเข้ามาแก้ไข และทำให้เกิดการวนกลับไปทำงานซ้ำ การวิเคราะห์ความถี่ของข้อผิดพลาดช่วยกำหนดแนวทางปรับปรุงการทดสอบในเครื่องหรือคุณภาพโค้ด.
แหล่งข้อมูล
อนุมานจาก GitHub Checks API หรือ Statuses API เมื่อ check run หรือการอัปเดตสถานะแจ้งว่า 'failure' หรือ 'completed' พร้อมผลสรุป 'failure'.
บันทึก
ติดตาม Checks API เพื่อดูผลสรุป 'failure' ของชุดการตรวจสอบที่เกี่ยวข้อง.
ประเภทเหตุการณ์
inferred
|
|||
|
Push โค้ดไปยัง PR
|
แสดงการอัปเดตโค้ดที่ส่งให้ตรวจสอบ ไม่ว่าจะเป็นส่วนหนึ่งของ PR ครั้งแรกหรือการแก้ไขตามข้อเสนอแนะ ระบบจะบันทึกเหตุการณ์นี้ทุกครั้งที่มีการ push commit ใหม่ไปยัง Branch ที่เชื่อมกับ pull request ซึ่งยังเปิดอยู่. | ||
|
เหตุผลที่สำคัญ
การติดตามเหตุการณ์เหล่านี้สำคัญต่อการระบุการวนกลับไปแก้งาน หากมีการ push หลายครั้งหลังการตรวจสอบ แสดงว่าต้องแก้ไขโค้ด ซึ่งส่งผลต่อระยะเวลาของวงจรโดยรวม.
แหล่งข้อมูล
เหตุการณ์นี้บันทึกโดยตรงในไทม์ไลน์ของ pull request โดยมักระบุว่ามีการเพิ่ม commit คุณบันทึกได้จาก webhook 'push' หรือจากการติดตาม commit ที่เชื่อมกับ PR.
บันทึก
ติดตามเหตุการณ์ 'push' บน Branch ที่เชื่อมกับ pull request ซึ่งยังเปิดอยู่.
ประเภทเหตุการณ์
explicit
|
|||
|
ขอให้ตรวจสอบโค้ด
|
ผู้สร้าง pull request ขอให้สมาชิกทีมหรือทีมที่ระบุเข้าตรวจสอบโค้ดอย่างเป็นทางการ การดำเนินการนี้ทำได้ผ่าน UI หรือ API ของ GitHub และจะแจ้งเตือนไปยังผู้ตรวจสอบที่ได้รับคำขอ. | ||
|
เหตุผลที่สำคัญ
กิจกรรมนี้เป็นจุดเริ่มต้นอย่างเป็นทางการของการส่งต่องานเข้าสู่ขั้นตอนตรวจสอบโค้ด เวลาตั้งแต่เหตุการณ์นี้จนถึงการส่งผลตรวจสอบช่วยวัดการตอบสนองของผู้ตรวจสอบและระบุคอขวดที่อาจเกิดขึ้น.
แหล่งข้อมูล
บันทึกจากสตรีมเหตุการณ์ของ GitHub Pull Request API หรือ webhook โดย action ของเหตุการณ์คือ 'review_requested'.
บันทึก
รับฟัง action 'review_requested' ของ pull request.
ประเภทเหตุการณ์
explicit
|
|||
|
นำระบบขึ้นใช้งานสำเร็จ
|
นำการเปลี่ยนแปลงโค้ดขึ้นสู่สภาพแวดล้อมที่กำหนด เช่น staging หรือ production สำเร็จ โดยทั่วไปบันทึกเหตุการณ์นี้ผ่าน GitHub Deployments API ซึ่งมักเริ่มทำงานจาก GitHub Action หลังรวมโค้ดแล้ว. | ||
|
เหตุผลที่สำคัญ
แสดงการเปลี่ยนผ่านของโค้ดจาก repository ไปสู่สภาพแวดล้อมที่ใช้งานจริง การติดตามเหตุการณ์นี้จำเป็นต่อการวัดระยะเวลาตั้งแต่เริ่มมีแนวคิดจนถึงขึ้น production.
แหล่งข้อมูล
บันทึกผ่าน Deployments API โดยบริการภายนอกหรือ GitHub Action จะสร้าง deployment แล้วอัปเดตสถานะเป็น 'success'.
บันทึก
ติดตามเหตุการณ์สถานะ deployment ผ่าน webhook เพื่อดูสถานะ 'success'.
ประเภทเหตุการณ์
inferred
|
|||
|
เปิด Issue อีกครั้ง
|
เปิด Issue ที่ปิดไปแล้วอีกครั้ง โดยทั่วไปเกิดจากการแก้ไขยังไม่เพียงพอหรือพบปัญหาที่เกิดซ้ำ เหตุการณ์นี้บันทึกโดยตรงและเริ่มวงจรของรายการพัฒนาใหม่. | ||
|
เหตุผลที่สำคัญ
เหตุการณ์นี้บ่งชี้ว่ามีการวนกลับไปแก้งานครั้งสำคัญ ซึ่งอาจหมายถึงข้อบกพร่องหลุดไปถึง production หรือแก้ไขไม่ครบ การติดตามความถี่เป็นตัวชี้วัดสำคัญของคุณภาพซอฟต์แวร์โดยรวม.
แหล่งข้อมูล
เหตุการณ์นี้บันทึกโดยตรงจากสตรีมเหตุการณ์ของ GitHub Issues API โดยประเภทเหตุการณ์คือ 'reopened'.
บันทึก
รับฟังเหตุการณ์ 'reopened' ของ Issue ผ่าน webhook หรือการเรียก API เป็นระยะ.
ประเภทเหตุการณ์
explicit
|
|||
|
ผู้ตรวจสอบขอให้แก้ไข
|
ผู้ตรวจสอบตรวจโค้ดเสร็จแล้วและเห็นว่าต้องแก้ไขก่อนอนุมัติ pull request ผู้ตรวจสอบส่งผลการตรวจสอบอย่างเป็นทางการด้วยสถานะ 'request_changes'. | ||
|
เหตุผลที่สำคัญ
เหตุการณ์นี้แสดงการวนกลับไปแก้งานอย่างชัดเจน การวิเคราะห์ความถี่ช่วยระบุปัญหาด้านคุณภาพ ข้อกำหนดที่ไม่ชัดเจน หรือประเด็นที่ควรฝึกอบรมนักพัฒนาเพิ่มเติม.
แหล่งข้อมูล
บันทึกจาก GitHub Pull Request API หรือ webhook เมื่อส่งผลตรวจสอบด้วยสถานะ 'CHANGES_REQUESTED'.
บันทึก
กรองเหตุการณ์ส่งผลตรวจสอบ pull request โดยเลือกสถานะ 'CHANGES_REQUESTED'.
ประเภทเหตุการณ์
explicit
|
|||
|
สร้าง Branch
|
แสดงจุดเริ่มต้นของการพัฒนางานใน Issue เมื่อนักพัฒนาสร้าง Branch ใหม่จากโค้ดหลัก ระบบจะบันทึกเหตุการณ์นี้เมื่อมีการ push Branch ใหม่ไปยัง repository ซึ่งชื่อ Branch มักมีหมายเลข Issue อยู่ด้วย. | ||
|
เหตุผลที่สำคัญ
แสดงการเปลี่ยนจากขั้นวางแผนไปสู่การลงมือเขียนโค้ด การวัดเวลาตั้งแต่สร้าง Issue จนถึงเหตุการณ์นี้ช่วยวิเคราะห์เวลาที่นักพัฒนาเริ่มรับงานและความล่าช้าของงานค้างในช่วงแรก.
แหล่งข้อมูล
บันทึกผ่าน GitHub Git API หรือ webhook ที่รับฟังเหตุการณ์ 'create' ประเภท 'branch' โดยมักต้องเชื่อมชื่อ Branch กับ Issue ผ่านรูปแบบการตั้งชื่อ เช่น 'feature/issue-123'.
บันทึก
แยกวิเคราะห์เหตุการณ์ webhook 'create' สำหรับ Branch ใหม่ แล้วเชื่อมโยงกับ Issue.
ประเภทเหตุการณ์
explicit
|
|||
คู่มือการดึงข้อมูล
พร้อมเริ่มต้นหรือยัง?
ใช้เทมเพลตนี้เตรียมข้อมูลและเริ่มปรับปรุงวงจรการพัฒนาซอฟต์แวร์ ค้นหาจุดที่ทำงานได้ไม่มีประสิทธิภาพและช่วยให้เผยแพร่ซอฟต์แวร์ได้เร็วขึ้นและราบรื่นขึ้นตั้งแต่วันนี้.
ยกระดับ SDLC ด้วยการค้นหาจุดที่ทำงานได้ไม่มีประสิทธิภาพ
ลดระยะเวลาต่อรอบลง 30% และทำให้กระบวนการพัฒนาบน GitHub คล่องตัวขึ้น.
ไม่ต้องใช้บัตรเครดิต ตั้งค่าเสร็จภายในไม่กี่นาที.