เทมเพลตข้อมูลวงจรการพัฒนาซอฟต์แวร์ของคุณ
เทมเพลตข้อมูลวงจรการพัฒนาซอฟต์แวร์ของคุณ
- แอตทริบิวต์ที่แนะนำให้เก็บ
- กิจกรรมหลักที่ควรติดตาม
- แนวทางนำข้อมูลออกจาก ServiceNow DevOps
แอตทริบิวต์ของวงจรการพัฒนาซอฟต์แวร์
| ชื่อ | คำอธิบาย | ||
|---|---|---|---|
| ชื่อกิจกรรม ActivityName | ชื่อเหตุการณ์เฉพาะที่เกิดขึ้นในวงจรการพัฒนา เช่น 'เริ่มพัฒนา' หรือ 'ตรวจสอบโค้ดแล้ว'. | ||
| คำอธิบาย คุณลักษณะนี้บันทึกชื่อของแต่ละหมุดหมายหรืองานที่เสร็จสิ้นในวงจรการพัฒนาซอฟต์แวร์ กิจกรรมเหล่านี้เป็นขั้นตอนต่อเนื่องของกระบวนการ ตั้งแต่การสร้างรายการจนถึงการนำระบบขึ้นใช้งาน การวิเคราะห์ลำดับและความถี่ของกิจกรรมเหล่านี้เป็นหน้าที่หลักของ process mining ช่วยสร้างแผนผังกระบวนการ ระบุคอขวดระหว่างขั้นตอน และชี้ให้เห็นรูปแบบกระบวนการที่ไม่เป็นไปตามข้อกำหนดหรือไม่มีประสิทธิภาพ รายการกิจกรรมที่กำหนดไว้ประกอบด้วยขั้นตอนสำคัญ เช่น การออกแบบ การพัฒนา การทดสอบ และการนำระบบขึ้นใช้งาน. เหตุผลที่สำคัญ คุณลักษณะนี้กำหนดขั้นตอนในแผนผังกระบวนการ ช่วยวิเคราะห์การไหลของกระบวนการ ระบุคอขวด และค้นหาจุดที่เบี่ยงเบนจาก SDLC มาตรฐาน. แหล่งข้อมูล โดยทั่วไปได้จากการจับคู่การเปลี่ยนสถานะ ระเบียนเหตุการณ์ หรือรายการในบันทึกการตรวจสอบ กับรายการชื่อกิจกรรมมาตรฐาน ตัวอย่างเช่น การเปลี่ยนฟิลด์ 'state' เป็น 'In Progress' อาจจับคู่กับ 'เริ่มพัฒนา'. ตัวอย่าง เริ่มพัฒนาบันทึกโค้ดทดสอบ QA เสร็จสิ้นนำระบบขึ้นใช้งานจริงแล้ว | |||
| รายการพัฒนา DevelopmentItem | รหัสเฉพาะของหน่วยงานหนึ่งรายการ เช่น ฟีเจอร์ bug หรือ task ที่ดำเนินไปตามวงจรการพัฒนา. | ||
| คำอธิบาย รายการพัฒนาใช้เป็นรหัสเคสหลักเพื่อแทนหน่วยงานที่กำลังติดตาม โดยเชื่อมโยงกิจกรรมทั้งหมดของรายการนั้น ตั้งแต่เริ่มคิดและวางแผน ไปจนถึงการพัฒนา การทดสอบ และการนำระบบขึ้นใช้งาน ในการวิเคราะห์ process mining คุณลักษณะนี้เป็นองค์ประกอบสำคัญสำหรับสร้างเส้นทางการทำงานของแต่ละรายการขึ้นใหม่ ช่วยให้เห็นภาพการไหลของกระบวนการ คำนวณระยะเวลารอบการทำงานทั้งหมด และระบุรูปแบบกระบวนการของฟีเจอร์หรือการแก้ bug แต่ละรายการ ทุกเหตุการณ์ในบันทึกต้องเชื่อมโยงกับรายการพัฒนา เพื่อสร้างแผนผังกระบวนการที่สอดคล้องกัน. เหตุผลที่สำคัญ นี่คือรหัสหลักที่เชื่อมกิจกรรมพัฒนาที่เกี่ยวข้องทั้งหมดให้เป็นกระบวนการเดียว ทำให้วิเคราะห์วงจรการทำงานทั้งหมดของแต่ละรายการได้. แหล่งข้อมูล โดยทั่วไป รหัสนี้เป็นคีย์หลักจากตารางที่จัดการ story, bug หรือ task เช่น ตาราง 'rm_story', 'rm_bug' หรือ 'task' ใน ServiceNow. ตัวอย่าง STRY0010015BUG0034092TASK0050118 | |||
| เวลาเริ่มต้น EventTime | เวลาที่ระบุอย่างแม่นยำว่ากิจกรรมหรือเหตุการณ์เกิดขึ้นเมื่อใด. | ||
| คำอธิบาย คุณลักษณะนี้ระบุวันที่และเวลาที่บันทึกกิจกรรมแต่ละรายการในวงจรการพัฒนา จำเป็นต่อการเรียงลำดับเหตุการณ์ตามเวลาและการวิเคราะห์ทุกประเภทที่อิงเวลา ใน process mining จะใช้เวลาเริ่มต้นคำนวณระยะเวลาระหว่างกิจกรรม ระบุเวลารอ และวัดระยะเวลารอบการทำงานทั้งหมดของกระบวนการ นอกจากนี้ยังเป็นองค์ประกอบสำคัญของแดชบอร์ดวิเคราะห์ประสิทธิภาพ เช่น การวิเคราะห์ระยะเวลารอบการทำงาน SDLC ตั้งแต่ต้นจนจบ และใช้คำนวณตัวชี้วัดประสิทธิภาพหลัก เช่น ระยะเวลาตั้งแต่เริ่มจนตรวจสอบโค้ดเสร็จ. เหตุผลที่สำคัญ เวลานี้จำเป็นต่อการเรียงลำดับเหตุการณ์ให้ถูกต้องและคำนวณตัวชี้วัดประสิทธิภาพทั้งหมด รวมถึงระยะเวลารอบการทำงาน ระยะเวลากิจกรรม และเวลารอ. แหล่งข้อมูล โดยทั่วไปพบในฟิลด์เวลาที่ระบบสร้างขึ้น เช่น 'sys_updated_on' หรือ 'sys_created_on' ในบันทึกการตรวจสอบหรือตาราง task. ตัวอย่าง 2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-11-01T09:15:00Z | |||
| ระบบต้นทาง SourceSystem | ระบุระบบที่ดึงข้อมูลมาใช้ ซึ่งในกรณีนี้คือ ServiceNow DevOps. | ||
| คำอธิบาย คุณลักษณะนี้ระบุระบบต้นทางของข้อมูลเหตุการณ์ สำหรับกระบวนการนี้ ค่าจะเป็น 'ServiceNow DevOps' เสมอ แม้ค่าจะดูเหมือนไม่เปลี่ยนแปลง แต่การระบุระบบต้นทางไว้อย่างชัดเจนมีความสำคัญต่อการกำกับดูแลข้อมูล และมีประโยชน์ในสภาพแวดล้อมที่อาจรวมข้อมูลจากหลายระบบ เช่น Jira หรือ Azure DevOps ช่วยให้ทราบที่มาของข้อมูลอย่างชัดเจนและวินิจฉัยปัญหาด้านคุณภาพข้อมูลหรือการดึงข้อมูลได้ง่ายขึ้น. เหตุผลที่สำคัญ ช่วยติดตามที่มาของข้อมูลและรักษาความถูกต้องของข้อมูล โดยเฉพาะเมื่อนำข้อมูลจากเครื่องมือพัฒนาหลายระบบมารวมกัน. แหล่งข้อมูล เป็นค่าคงที่ที่ควรเพิ่มระหว่างขั้นตอนดึงและแปลงข้อมูล. ตัวอย่าง ServiceNow DevOps | |||
| อัปเดตข้อมูลล่าสุด LastDataUpdate | เวลาที่บันทึกว่ามีการรีเฟรชข้อมูลของบันทึกเหตุการณ์นี้จากระบบต้นทางครั้งล่าสุด. | ||
| คำอธิบาย คุณลักษณะนี้บันทึกเวลาที่ดึงหรืออัปเดตชุดข้อมูลจาก ServiceNow DevOps ครั้งล่าสุด โดยใช้กับชุดข้อมูลทั้งหมด ไม่ใช่เหตุการณ์แต่ละรายการ เวลานี้สำคัญต่อการประเมินว่าข้อมูลที่ใช้วิเคราะห์เป็นข้อมูลล่าสุดเพียงใด ช่วยให้ผู้ใช้ทราบว่าข้อมูลเชิงลึกเกี่ยวกับกระบวนการเป็นปัจจุบันแค่ไหน และช่วยวางกำหนดการรีเฟรชข้อมูล การแสดงข้อมูลนี้บนแดชบอร์ดช่วยให้เข้าใจบริบทของตัวชี้วัดและภาพประกอบทั้งหมด และตัดสินใจจากข้อมูลที่ทันเวลา. เหตุผลที่สำคัญ ให้บริบทสำคัญเกี่ยวกับความใหม่ของข้อมูล เพื่อให้ผู้ใช้ทราบว่าการวิเคราะห์กระบวนการอ้างอิงข้อมูลล่าสุดเพียงใด. แหล่งข้อมูล ระบบสร้างและเพิ่มเวลานี้ระหว่างการดึงข้อมูล เพื่อบันทึกเวลาที่ดำเนินการดึงข้อมูล. ตัวอย่าง 2023-11-15T08:00:00Z | |||
| กลุ่มผู้รับผิดชอบ AssignmentGroup | ทีมที่รับผิดชอบรายการพัฒนาในขณะที่เกิดกิจกรรม. | ||
| คำอธิบาย แอตทริบิวต์นี้ระบุทีมที่ได้รับมอบหมายให้ทำรายการงาน เช่น 'ทีมพัฒนา Frontend', 'ทีมบริการ Backend' หรือ 'ทีม QA' เมื่อรายการงานดำเนินไป มักมีการส่งต่องานระหว่างกลุ่มผู้รับผิดชอบ การติดตามกลุ่มผู้รับผิดชอบช่วยให้เข้าใจการทำงานร่วมกันระหว่างทีมและการส่งต่องาน รวมถึงระบุความล่าช้าที่เกิดขึ้นเมื่องานย้ายจากทีมหนึ่งไปอีกทีมหนึ่งได้ แอตทริบิวต์นี้ยังช่วยวิเคราะห์ผลการดำเนินงานและปริมาณงานของแต่ละทีม ตลอดจนระบุทีมที่เป็นคอขวดในภาพรวมของกระบวนการ. เหตุผลที่สำคัญ ติดตามทีมที่รับผิดชอบงาน เพื่อวิเคราะห์ผลการดำเนินงานและปริมาณงานของแต่ละทีม รวมถึงประสิทธิภาพในการส่งต่องานระหว่างทีม. แหล่งข้อมูล ข้อมูลนี้จัดเก็บในฟิลด์ 'assignment_group' ซึ่งเป็นฟิลด์มาตรฐานในตารางที่เกี่ยวข้องกับงานของ ServiceNow. ตัวอย่าง วิศวกรรมแพลตฟอร์มทีมแอปมือถือประกันคุณภาพDevOps | |||
| นักพัฒนาที่ได้รับมอบหมาย AssignedDeveloper | ชื่อหรือรหัสของนักพัฒนาหรือผู้ใช้ที่ได้รับมอบหมายให้ดูแลรายการพัฒนาในขณะที่เกิดกิจกรรม. | ||
| คำอธิบาย คุณลักษณะนี้ระบุผู้รับผิดชอบงานหรือกิจกรรมแต่ละรายการ โดยค่าเปลี่ยนแปลงได้เมื่อรายการพัฒนาเคลื่อนผ่านขั้นตอนและทีมต่าง ๆ คุณลักษณะนี้สำคัญต่อการวิเคราะห์การจัดสรรทรัพยากร ปริมาณงาน และการส่งต่องาน ใช้กับแดชบอร์ด 'ปริมาณงานและการส่งต่องานของนักพัฒนา' และ KPI 'จำนวนกิจกรรมต่อนักพัฒนา' ได้โดยตรง เมื่อติดตามการเปลี่ยนแปลงของฟิลด์นี้ คุณจะวัดเวลาส่งต่องานและระบุคอขวดในการทำงานร่วมกันระหว่างนักพัฒนา หรือระหว่างทีมพัฒนาและ QA ได้. เหตุผลที่สำคัญ จำเป็นต่อการวิเคราะห์ตามทรัพยากร ทั้งการกระจายปริมาณงาน ประสิทธิภาพการส่งต่องาน และรูปแบบประสิทธิภาพเฉพาะของแต่ละทีม. แหล่งข้อมูล โดยทั่วไปข้อมูลนี้จัดเก็บไว้ในฟิลด์ 'assigned_to' ของตารางที่เกี่ยวข้องกับ task ใน ServiceNow. ตัวอย่าง David MillerAnna WilliamsJames Brown | |||
| ประเภทรายการพัฒนา DevelopmentItemType | การจัดประเภทของรายการงาน เช่น 'ฟีเจอร์', 'บั๊ก', 'หนี้ทางเทคนิค' หรือ 'งาน'. | ||
| คำอธิบาย แอตทริบิวต์นี้ใช้แยกประเภทงานที่ดำเนินอยู่ในกระบวนการ SDLC ตัวอย่างเช่น กระบวนการแก้บั๊กร้ายแรงอาจแตกต่างจากการพัฒนาฟีเจอร์ใหม่ และอาจใช้เวลาน้อยกว่า การวิเคราะห์กระบวนการตามประเภทของรายการงานช่วยให้เข้าใจผลการดำเนินงานได้ละเอียดขึ้น เช่น บั๊กมีอัตราการแก้งานซ้ำสูงกว่าฟีเจอร์ใหม่หรือไม่ หรือระยะเวลาการลดหนี้ทางเทคนิคเป็นไปตามที่คาดหวังหรือไม่ การแบ่งข้อมูลเช่นนี้ให้ข้อมูลเชิงลึกมากกว่าการดูทุกงานรวมกันเป็นกระบวนการเดียว. เหตุผลที่สำคัญ ใช้แยกประเภทงาน เช่น ฟีเจอร์และบั๊ก ซึ่งอาจมีเส้นทางกระบวนการ ลำดับความสำคัญ และระยะเวลาที่คาดหวังแตกต่างกัน. แหล่งข้อมูล ระบุประเภทได้จากตารางต้นทางของระเบียน เช่น 'rm_story' กับ 'rm_bug' หรือจากฟิลด์ 'type' ในตารางงานทั่วไป. ตัวอย่าง ฟีเจอร์บั๊กงานงานทดลองศึกษา | |||
| เป็นการแก้งานซ้ำหรือไม่ IsRework | ค่าสถานะแบบบูลีนที่เป็นจริงเมื่อกิจกรรมเป็นส่วนหนึ่งของการวนกลับไปแก้งาน เช่น กลับไปพัฒนาต่อหลังการทดสอบ. | ||
| คำอธิบาย แอตทริบิวต์ที่ได้จากการคำนวณนี้ใช้ระบุกิจกรรมที่เกิดขึ้นหลังจากกระบวนการย้อนกลับไปยังขั้นตอนก่อนหน้า ตัวอย่างเช่น หากกิจกรรม 'เริ่มพัฒนา' เกิดขึ้นหลัง 'ทดสอบ QA เสร็จแล้ว' สำหรับรายการเดียวกัน ระบบจะระบุว่าเป็นการแก้งานซ้ำ ค่าสถานะนี้จำเป็นต่อการวัดและแสดงผลการแก้งานซ้ำ ช่วยสนับสนุนแดชบอร์ด 'วิเคราะห์เส้นทางการแก้งานซ้ำและการปฏิเสธงาน' โดยตรง และใช้คำนวณ KPI 'อัตราการแก้งานซ้ำหลังทดสอบ' เมื่อติดป้ายกำกับเหตุการณ์เหล่านี้แล้ว นักวิเคราะห์จะกรองและวิเคราะห์ความถี่ สาเหตุ และผลกระทบของการแก้งานซ้ำต่อระยะเวลารอบการทำงานโดยรวมได้ง่ายขึ้น. เหตุผลที่สำคัญ ค่าสถานะนี้ช่วยวัดและวิเคราะห์การแก้งานซ้ำได้ง่ายขึ้น ทำให้ประเมินคุณภาพกระบวนการและระบุสาเหตุที่แท้จริงของการทำงานซ้ำได้. แหล่งข้อมูล เครื่องมือ process mining คำนวณแอตทริบิวต์นี้โดยวิเคราะห์ลำดับกิจกรรมของแต่ละเคส เพื่อตรวจจับการย้อนกลับในกระบวนการ. ตัวอย่าง truefalse | |||
| โมดูล/คอมโพเนนต์ที่ได้รับผลกระทบ ModuleComponentAffected | โมดูลซอฟต์แวร์ แอปพลิเคชัน หรือคอมโพเนนต์ที่เกี่ยวข้องกับรายการพัฒนาโดยเฉพาะ. | ||
| คำอธิบาย แอตทริบิวต์นี้จัดหมวดหมู่งานพัฒนาตามส่วนของระบบที่ได้รับผลกระทบ เช่น microservice, คอมโพเนนต์ UI หรือแอปพลิเคชัน backend การแบ่งกระบวนการตามโมดูลหรือคอมโพเนนต์ช่วยให้ระบุคอขวดเฉพาะจุดได้ แดชบอร์ด 'ข้อมูลเชิงลึกเกี่ยวกับคอขวดของแต่ละคอมโพเนนต์' และ KPI 'ระยะเวลาเฉลี่ยในแต่ละขั้นตอนแยกตามคอมโพเนนต์' ใช้แอตทริบิวต์นี้เพื่อตรวจสอบว่าส่วนใดของโค้ดมีรอบการพัฒนาที่ยาวนานกว่า อัตราการแก้งานซ้ำสูงกว่า หรือการนำขึ้นใช้งานล้มเหลวบ่อยกว่าอย่างต่อเนื่อง ข้อมูลนี้ช่วยให้คุณมุ่งปรับปรุงจุดที่จำเป็นได้ตรงจุด. เหตุผลที่สำคัญ ช่วยแบ่งการวิเคราะห์ตามแอปพลิเคชันหรือคอมโพเนนต์ เพื่อแยกดูคอขวดหรือปัญหาด้านคุณภาพที่เกิดกับบางส่วนของระบบโดยเฉพาะ. แหล่งข้อมูล ข้อมูลนี้มักอยู่ในฟิลด์ที่กำหนดเอง หรือเป็นการอ้างอิงไปยัง Configuration Management Database (CMDB) ซึ่งเชื่อมรายการงานกับระเบียน 'cmdb_ci' โปรดดูเอกสาร ServiceNow DevOps. ตัวอย่าง บริการเรียกเก็บเงินUI สำหรับการยืนยันตัวตนผู้ใช้ฐานข้อมูลการรายงานAPI Gateway | |||
| ระยะเวลารอบการพัฒนารายการ DevelopmentItemCycleTime | เวลารวมตั้งแต่สร้างรายการพัฒนาจนปิดงานหรือนำขึ้นใช้งานเสร็จสิ้น. | ||
| คำอธิบาย แอตทริบิวต์นี้เป็นตัวชี้วัดที่คำนวณจากระยะเวลาตั้งแต่ต้นจนจบของรายการพัฒนาแต่ละรายการ โดยหาผลต่างระหว่างเวลาของกิจกรรมแรกสุดกับกิจกรรมสุดท้ายของแต่ละเคส นี่คือตัวชี้วัดผลการดำเนินงานหลักของกระบวนการ SDLC และใช้คำนวณ KPI 'ระยะเวลารอบการพัฒนา SDLC เฉลี่ย' โดยตรง ช่วยวัดความเร็วและประสิทธิภาพของกระบวนการในภาพรวม การวิเคราะห์ตัวชี้วัดนี้ตามช่วงเวลาและมิติต่างๆ เช่น ลำดับความสำคัญหรือทีม ช่วยติดตามผลของการปรับปรุงกระบวนการได้. เหตุผลที่สำคัญ แสดงระยะเวลาตั้งแต่ต้นจนจบของรายการงาน ซึ่งเป็นตัวชี้วัดสำคัญในการวัดประสิทธิภาพและความเร็วของกระบวนการโดยรวม. แหล่งข้อมูล ฟิลด์นี้ไม่มีในระบบต้นทาง เครื่องมือ process mining จะคำนวณโดยนำ StartTime ต่ำสุดมาลบออกจาก StartTime สูงสุดของแต่ละ CaseId. ตัวอย่าง 15 วัน 4 ชั่วโมง3 วัน 12 ชั่วโมง32 วัน 8 ชั่วโมง | |||
| ลำดับความสำคัญ DevelopmentItemPriority | ระดับความสำคัญที่กำหนดให้รายการพัฒนา เช่น 'สูง', 'ปานกลาง' หรือ 'ต่ำ'. | ||
| คำอธิบาย คุณลักษณะนี้จัดกลุ่มรายการพัฒนาตามความเร่งด่วนทางธุรกิจ ระดับความสำคัญช่วยให้ทีมมุ่งเน้นงานที่สำคัญที่สุด และมักใช้บริหาร SLA กับความคาดหวังของผู้มีส่วนเกี่ยวข้อง ใน process mining ลำดับความสำคัญเป็นมิติสำคัญสำหรับการวิเคราะห์เปรียบเทียบ คุณสามารถกรองแผนผังกระบวนการเพื่อดูว่ารายการที่มีความสำคัญสูงใช้เส้นทางที่เร็วขึ้นหรือแตกต่างออกไปหรือไม่ คุณลักษณะนี้จำเป็นต่อแดชบอร์ดและ KPI 'ระยะเวลาส่งมอบฟีเจอร์ที่มีความสำคัญสูง' เพื่อช่วยตรวจสอบว่ารายการสำคัญได้รับการเร่งดำเนินการจริงหรือไม่. เหตุผลที่สำคัญ ช่วยกรองและเปรียบเทียบกระบวนการตามระดับความสำคัญ เพื่อตรวจสอบว่ารายการที่มีความสำคัญสูงได้รับการดำเนินการเร็วและมีประสิทธิภาพกว่าหรือไม่. แหล่งข้อมูล โดยทั่วไปเป็นฟิลด์มาตรฐานชื่อ 'priority' ในตารางที่เกี่ยวข้องกับ task ของ ServiceNow. ตัวอย่าง 1 - วิกฤต2 - สูง3 - ปานกลาง4 - ต่ำ | |||
| สถานะรายการพัฒนา DevelopmentItemState | สถานะของรายการพัฒนา ณ เวลาที่เกิดเหตุการณ์ เช่น 'เปิด', 'กำลังดำเนินการ' หรือ 'ปิดแล้ว'. | ||
| คำอธิบาย แอตทริบิวต์นี้แสดงสถานะอย่างเป็นทางการของรายการพัฒนาใน ServiceNow กิจกรรมคือขั้นตอนที่ได้จากข้อมูลกระบวนการ ส่วนสถานะจะแสดงขั้นตอนอย่างเป็นทางการในเวิร์กโฟลว์ของระบบ โดยทั่วไป ระบบใช้สถานะเป็นข้อมูลต้นทางในการระบุกิจกรรม และใช้ตรวจสอบความถูกต้องของข้อมูลหรือสร้างมุมมองกระบวนการระดับภาพรวมที่เข้าใจง่ายขึ้น ตัวอย่างเช่น การวิเคราะห์เวลาที่ใช้ในแต่ละสถานะช่วยให้เห็นคอขวดในอีกมุมหนึ่ง เมื่อเทียบกับการวิเคราะห์เวลาระหว่างกิจกรรม นอกจากนี้ยังช่วยระบุรายการที่หยุดค้างหรือดำเนินการเสร็จแล้วได้ด้วย. เหตุผลที่สำคัญ แสดงสถานะอย่างเป็นทางการของรายการงานในระบบ ซึ่งมักใช้เป็นข้อมูลต้นทางในการระบุกิจกรรม และนำไปตรวจสอบความถูกต้องหรือวิเคราะห์สถานะในภาพรวมได้. แหล่งข้อมูล โดยทั่วไป ฟิลด์มาตรฐานนี้มีชื่อว่า 'state' หรือ 'stage' ในตารางที่เกี่ยวข้องกับงานของ ServiceNow. ตัวอย่าง รอดำเนินการกำลังดำเนินงานพร้อมทดสอบปิดงานเรียบร้อย | |||
| รหัส Commit CommitId | ตัวระบุเฉพาะของ commit ในซอร์สโค้ดที่เกี่ยวข้องกับงานพัฒนา. | ||
| คำอธิบาย แอตทริบิวต์นี้เชื่อมรายการพัฒนาโดยตรงกับการเปลี่ยนแปลงโค้ดในคลังซอร์สโค้ด เช่น Git โดยระบบจะบันทึกเมื่อเกิดกิจกรรม 'Commit โค้ดแล้ว' ใน process mining รหัส Commit ช่วยเพิ่มรายละเอียดในการวิเคราะห์ โดยเชื่อมข้อมูลกระบวนการกับข้อมูลด้านวิศวกรรม นักวิเคราะห์สามารถตรวจสอบย้อนกลับจากการนำระบบขึ้นใช้งานที่มีปัญหาไปยังการเปลี่ยนแปลงโค้ดที่เกี่ยวข้อง หรือเปรียบเทียบความซับซ้อนของโค้ดกับระยะเวลารอบการพัฒนาได้ จึงช่วยวิเคราะห์สาเหตุที่แท้จริงในระดับเทคนิคได้ละเอียดขึ้น. เหตุผลที่สำคัญ เชื่อมเหตุการณ์ในกระบวนการกับการเปลี่ยนแปลงโค้ดโดยเฉพาะ เพื่อวิเคราะห์หาสาเหตุที่แท้จริงได้ละเอียดขึ้น ด้วยการเปรียบเทียบตัวชี้วัดกระบวนการกับรายละเอียดระดับโค้ด. แหล่งข้อมูล ข้อมูลนี้บันทึกผ่านการเชื่อมต่อ ServiceNow DevOps กับระบบจัดการซอร์สโค้ด เช่น Git หรือ SVN โดยจัดเก็บไว้ในตารางที่เกี่ยวข้องและเชื่อมกับรายการพัฒนา. ตัวอย่าง a1b2c3d4e5f6f0e9d8c7b6a59a8b7c6d5e4f | |||
| เวลาสิ้นสุด EventEndTime | เวลาที่ระบุอย่างแม่นยำว่ากิจกรรมเสร็จสิ้นเมื่อใด สำหรับเหตุการณ์ที่เกิดขึ้นทันที จะตรงกับเวลาเริ่มต้น. | ||
| คำอธิบาย คุณลักษณะนี้ระบุวันที่และเวลาที่กิจกรรมแต่ละรายการในวงจรการพัฒนาเสร็จสิ้น มีประโยชน์เป็นพิเศษกับกิจกรรมที่วัดระยะเวลาได้ เช่น 'ตรวจสอบโค้ดแล้ว' หรือ 'ทดสอบ QA' ใน process mining การมีทั้งเวลาเริ่มต้นและเวลาสิ้นสุดช่วยคำนวณเวลาที่ใช้ทำกิจกรรมได้อย่างแม่นยำ และแยกออกจากเวลารอระหว่างกิจกรรม ทำให้ระบุได้ว่าความล่าช้าเกิดจากงานที่ใช้เวลานานหรือการรอทรัพยากรนาน สำหรับเหตุการณ์ที่เกิดขึ้นทันที เช่น 'เริ่ม build' เวลาเริ่มต้นและเวลาสิ้นสุดอาจตรงกัน. เหตุผลที่สำคัญ ช่วยคำนวณเวลาที่ใช้ทำกิจกรรมได้อย่างแม่นยำ และแยกเวลาทำงานออกจากเวลารอ. แหล่งข้อมูล ข้อมูลนี้อาจต้องคำนวณขึ้นมา โดยอาจใช้เวลาเริ่มต้นของกิจกรรมถัดไป หรือใช้จากฟิลด์ 'end date' แยกต่างหาก หากระบบต้นทางมีฟิลด์นี้. ตัวอย่าง 2023-10-26T18:05:00Z2023-10-28T11:20:15Z2023-11-02T10:00:00Z | |||
| เวอร์ชันที่วางแผนจะเผยแพร่ PlannedReleaseVersion | ซอฟต์แวร์รุ่นหรือเวอร์ชันเป้าหมายที่วางแผนจะส่งมอบรายการพัฒนา. | ||
| คำอธิบาย แอตทริบิวต์นี้เชื่อมรายการพัฒนากับรุ่นที่วางแผนไว้โดยเฉพาะ เช่น 'เวอร์ชัน 2.3' หรือ 'รุ่นไตรมาส 4 ปี 2023' ซึ่งเป็นองค์ประกอบสำคัญของการบริหารโครงการและการวางแผนเผยแพร่ สำหรับ process mining แอตทริบิวต์นี้จำเป็นต่อแดชบอร์ด 'ติดตามการทำตามแผนเผยแพร่' เมื่อเปรียบเทียบวันที่เสร็จจริงกับวันที่วางแผนเผยแพร่ ทีมจะวัดได้ว่าทำงานตามกำหนดหรือไม่ ระบุรายการที่เสี่ยงส่งไม่ทันรุ่น และวิเคราะห์สาเหตุของความล่าช้าในการเผยแพร่ได้ นอกจากนี้ยังเชื่อมกระบวนการพัฒนาระดับงานเข้ากับเป้าหมายทางธุรกิจในภาพรวมโดยตรง. เหตุผลที่สำคัญ เชื่อมงานพัฒนากับรุ่นที่กำหนด เพื่อวิเคราะห์การทำงานตามกำหนดและผลกระทบของความล่าช้าในกระบวนการต่อกำหนดการเผยแพร่. แหล่งข้อมูล โดยทั่วไป ข้อมูลนี้จัดเก็บในฟิลด์ 'release' หรือ 'planned_release' ซึ่งมักอ้างอิงตารางการจัดการรุ่นใน ServiceNow โปรดดูเอกสาร ServiceNow DevOps. ตัวอย่าง v3.4.1รุ่นเผยแพร่ไตรมาส 1 ปี 2024เปิดใช้งาน Project Phoenix | |||
| สถานะการนำขึ้นใช้งาน DeploymentStatus | ระบุผลลัพธ์ของกิจกรรมการนำขึ้นใช้งาน โดยทั่วไปคือ 'สำเร็จ' หรือ 'ล้มเหลว'. | ||
| คำอธิบาย แอตทริบิวต์นี้บันทึกผลการนำระบบขึ้นใช้งานในสภาพแวดล้อมที่กำหนด เป็นข้อมูลสำคัญในการทำความเข้าใจความน่าเชื่อถือและเสถียรภาพของกระบวนการเผยแพร่ แอตทริบิวต์นี้จำเป็นต่อแดชบอร์ด 'แนวโน้มความสำเร็จและความล้มเหลวในการนำขึ้นใช้งาน' และ KPI 'อัตราความล้มเหลวในการนำขึ้นใช้งาน' การวิเคราะห์ความถี่และแนวโน้มของการนำขึ้นใช้งานที่ล้มเหลวช่วยให้องค์กรระบุปัญหาที่ซ่อนอยู่ในการทดสอบ โครงสร้างพื้นฐาน หรือการประสานงานการเผยแพร่ได้ และช่วยให้มุ่งปรับปรุงคุณภาพและความน่าเชื่อถือของการส่งมอบซอฟต์แวร์. เหตุผลที่สำคัญ วัดผลความสำเร็จของกิจกรรมการนำขึ้นใช้งานโดยตรง ซึ่งจำเป็นต่อการคำนวณอัตราความล้มเหลวและวิเคราะห์เสถียรภาพของกระบวนการเผยแพร่. แหล่งข้อมูล โดยทั่วไป สถานะนี้บันทึกไว้ในงานติดตามการนำขึ้นใช้งาน หรือระเบียนการทำงานของ CI/CD pipeline ที่เชื่อมต่อกับ ServiceNow DevOps. ตัวอย่าง สำเร็จล้มเหลวเสร็จสิ้นพร้อมคำเตือน | |||
| สาเหตุที่ต้องแก้งานซ้ำ ReworkReason | การจัดประเภทหรือคำอธิบายสาเหตุที่ต้องแก้รายการพัฒนาซ้ำหลังการทดสอบ. | ||
| คำอธิบาย เมื่อรายการไม่ผ่าน QA หรือ UAT แอตทริบิวต์นี้จะบันทึกสาเหตุที่ไม่ผ่าน เช่น ประเภทบั๊กเฉพาะ ความเข้าใจข้อกำหนดไม่ตรงกัน หรือปัญหาจากสภาพแวดล้อม ข้อมูลนี้ช่วยให้เข้าใจบริบทของแดชบอร์ด 'วิเคราะห์เส้นทางการแก้งานซ้ำและการปฏิเสธงาน' นักวิเคราะห์จะเห็นได้ไม่เพียงว่ามีการแก้งานซ้ำ แต่ยังเข้าใจสาเหตุด้วย จึงนำไปปรับปรุงได้ตรงจุด เช่น กำหนดข้อกำหนดให้ชัดเจนขึ้น เพิ่มการทดสอบระดับหน่วย หรือทำให้สภาพแวดล้อมทดสอบมีเสถียรภาพมากขึ้น เพื่อลดอัตราการแก้งานซ้ำโดยรวม. เหตุผลที่สำคัญ ช่วยให้เข้าใจสาเหตุของการแก้งานซ้ำในเชิงคุณภาพ และนำไปปรับปรุงกระบวนการได้ตรงจุด เพื่อยกระดับคุณภาพและลดการวนกลับไปทำงานซ้ำ. แหล่งข้อมูล ข้อมูลนี้อาจบันทึกในฟิลด์ 'close_notes' เมื่อการทดสอบไม่ผ่าน หรือในฟิลด์ที่กำหนดเองชื่อ 'rework_reason' โปรดดูเอกสาร ServiceNow DevOps. ตัวอย่าง ตีความข้อกำหนดไม่ตรงกันบั๊กที่เกิดซ้ำไม่ผ่านการทดสอบประสิทธิภาพปัญหา UI/UX | |||
กิจกรรมในวงจรการพัฒนาซอฟต์แวร์
| กิจกรรม | คำอธิบาย | ||
|---|---|---|---|
| การนำระบบขึ้นใช้งานล้มเหลว | หมายถึงการนำรายการพัฒนาขึ้นสู่สภาพแวดล้อมใช้งานจริงไม่สำเร็จ ServiceNow DevOps บันทึกเหตุการณ์นี้โดยตรงเมื่อไปป์ไลน์ CI/CD รายงานความล้มเหลว. | ||
| เหตุผลที่สำคัญ นี่คือจุดสิ้นสุดที่แสดงความล้มเหลว การวิเคราะห์ความถี่และสาเหตุเป็นกุญแจสำคัญในการเพิ่มเสถียรภาพของการเผยแพร่และลดอัตราความล้มเหลวในการนำระบบขึ้นใช้งาน. แหล่งข้อมูล ดึงข้อมูลจากค่า 'completion_status' ของระเบียน Pipeline Execution [sn_devops_pipeline_execution] หากสถานะเป็น 'Failed' ณ เวลาสิ้นสุด ให้ถือว่าเกิดเหตุการณ์นี้. บันทึก บันทึกเมื่อไปป์ไลน์นำระบบขึ้นใช้งานจริงรายงานสถานะล้มเหลว. ประเภทเหตุการณ์ explicit | |||
| ตรวจสอบโค้ดเสร็จสิ้น | กิจกรรมนี้หมายถึงการตรวจสอบโค้ดโดยเพื่อนร่วมทีมเสร็จสิ้น โดยทั่วไปเกี่ยวข้องกับ pull request หรือ merge request บันทึกเหตุการณ์นี้ได้โดยตรงผ่านการเชื่อมต่อ DevOps หรืออนุมานจากการเปลี่ยนสถานะของระเบียนที่เกี่ยวข้อง. | ||
| เหตุผลที่สำคัญ นี่คือจุดตรวจสอบคุณภาพที่สำคัญ การวิเคราะห์ระยะเวลาช่วยให้เห็นคอขวดในขั้นตอนตรวจสอบ ซึ่งมักเป็นสาเหตุของความล่าช้าใน SDLC. แหล่งข้อมูล ดึงข้อมูลจากเหตุการณ์ 'Merged' หรือ 'Completed' ของระเบียน Pull Request ในการเชื่อมต่อ Git ของ ServiceNow หรืออนุมานจากการเปลี่ยนสถานะรายการพัฒนาเป็น 'Code Review Complete'. บันทึก บันทึกเมื่อมีการ merge Pull Request ที่เชื่อมโยงกับรายการงาน. ประเภทเหตุการณ์ explicit | |||
| ทดสอบ QA เสร็จสิ้น | หมายถึงทีม Quality Assurance ทดสอบรายการพัฒนาเสร็จเรียบร้อย โดยทั่วไปอนุมานเมื่อสถานะของรายการออกจากขั้นตอนทดสอบไปเป็นสถานะอย่าง 'Ready for UAT' หรือ 'Done'. | ||
| เหตุผลที่สำคัญ หมุดหมายนี้หมายถึงการผ่านจุดตรวจสอบคุณภาพสำคัญ และเป็นเงื่อนไขก่อนเข้าสู่ขั้นตอนถัดไป เช่น User Acceptance Testing หรือการเตรียมเผยแพร่. แหล่งข้อมูล อนุมานจากเวลาที่สถานะเปลี่ยนจากสถานะทดสอบ เช่น 'In QA' ไปเป็นสถานะหลังทดสอบ เช่น 'Ready for UAT' หรือ 'Resolved'. บันทึก อ้างอิงเวลาที่สถานะเปลี่ยนจาก 'Testing' ไปเป็นสถานะถัดไป. ประเภทเหตุการณ์ inferred | |||
| นำระบบขึ้นใช้งานจริงแล้ว | เหตุการณ์นี้หมายถึงการนำระบบขึ้นสู่สภาพแวดล้อมใช้งานจริงเสร็จสมบูรณ์ ServiceNow DevOps บันทึกเหตุการณ์นี้โดยตรงเมื่อเครื่องมือ CI/CD รายงานว่าไปป์ไลน์ทำงานสำเร็จ. | ||
| เหตุผลที่สำคัญ นี่คือจุดสิ้นสุดที่แสดงความสำเร็จหลักของกระบวนการ SDLC เป็นการสิ้นสุดเส้นทางการส่งมอบคุณค่าและจำเป็นต่อการคำนวณระยะเวลารอบการทำงานทั้งหมด. แหล่งข้อมูล ดึงข้อมูลจากค่า 'completion_status' ของระเบียน Pipeline Execution [sn_devops_pipeline_execution] หรือ Stage Execution Run ที่เกี่ยวข้อง หากสถานะเป็น 'Success' ณ เวลาสิ้นสุด ให้ถือว่าเกิดเหตุการณ์นี้. บันทึก บันทึกเมื่อไปป์ไลน์นำระบบขึ้นใช้งานจริงเสร็จสมบูรณ์. ประเภทเหตุการณ์ explicit | |||
| เริ่มพัฒนา | กิจกรรมนี้หมายถึงจุดที่นักพัฒนาเริ่มเขียนโค้ดหรือนำรายการพัฒนาไปลงมือทำ โดยทั่วไปอนุมานจากการเปลี่ยนสถานะของรายการเป็น 'In Progress', 'Development' หรือ 'Coding'. | ||
| เหตุผลที่สำคัญ นี่คือหมุดหมายสำคัญที่บ่งบอกว่าเริ่มขั้นตอนสร้างผลงานที่เพิ่มคุณค่า ใช้วัดระยะเวลาตั้งแต่เริ่มงานของนักพัฒนาและระยะเวลารอบการตรวจสอบโค้ด. แหล่งข้อมูล อนุมานจากเวลาที่ฟิลด์ 'State' ในระเบียนรายการพัฒนา เช่น Story [rm_story] เปลี่ยนเป็น 'In Progress' หรือสถานะที่มีความหมายเทียบเท่า. บันทึก อ้างอิงเวลาที่สถานะเปลี่ยนเป็น 'In Progress' หรือค่าใกล้เคียงกัน. ประเภทเหตุการณ์ inferred | |||
| สร้างรายการพัฒนา | กิจกรรมนี้หมายถึงการสร้างรายการพัฒนาใหม่ เช่น story, bug หรือ epic ใน ServiceNow โดยทั่วไปจะบันทึกเหตุการณ์นี้โดยตรงเมื่อมีการเพิ่มระเบียนใหม่ลงในตารางที่เกี่ยวข้อง เช่น ตาราง Story [rm_story]. | ||
| เหตุผลที่สำคัญ นี่คือเหตุการณ์เริ่มต้นหลักของกระบวนการ SDLC ใช้วัดระยะเวลารอบการทำงานทั้งหมดตั้งแต่ต้นจนจบ และติดตามการรับคำขอเริ่มต้น. แหล่งข้อมูล บันทึกไว้ในตาราง sys_audit หรือ sys_history_line เมื่อสร้างระเบียนในตารางที่เกี่ยวข้องกับการพัฒนา เช่น Story [rm_story], Epic [rm_epic] หรือ Defect [rm_defect] โดยทั่วไปเวลา创建จะอยู่ในระเบียนนั้น. บันทึก ดึงข้อมูลจากเวลาที่สร้างระเบียนรายการพัฒนา. ประเภทเหตุการณ์ explicit | |||
| อนุมัติ UAT | หมายถึงผู้มีส่วนเกี่ยวข้องทางธุรกิจอนุมัติรายการพัฒนาอย่างเป็นทางการหลัง User Acceptance Testing เป็นหมุดหมายสำคัญที่อนุมานจากการเปลี่ยนสถานะ เช่น จาก 'In UAT' เป็น 'Ready for Release' หรือ 'Approved'. | ||
| เหตุผลที่สำคัญ นี่คือการอนุมัติขั้นสุดท้ายจากฝ่ายธุรกิจก่อนอนุญาตให้นำรายการขึ้นใช้งานจริง เป็นจุดตรวจสอบสำคัญด้านคุณภาพและการกำกับดูแล. แหล่งข้อมูล อนุมานจากการเปลี่ยนสถานะในระเบียนรายการพัฒนาที่แสดงว่า UAT เสร็จสมบูรณ์ โดยบันทึกไว้ในประวัติกิจกรรมของรายการ. บันทึก อนุมานจากการเปลี่ยนสถานะจาก 'UAT' เป็นสถานะที่อนุมัติแล้วหรือพร้อมเผยแพร่. ประเภทเหตุการณ์ inferred | |||
| เตรียมพร้อมสำหรับการเผยแพร่เวอร์ชัน | กิจกรรมนี้หมายถึงรายการพัฒนาผ่านจุดตรวจสอบคุณภาพทั้งหมดและถูกรวมไว้ในรุ่นเผยแพร่ที่ระบุ อนุมานได้เมื่อรายการเชื่อมโยงกับระเบียน Release หรือสถานะเปลี่ยนเป็น 'Ready for Deployment'. | ||
| เหตุผลที่สำคัญ ขั้นตอนนี้แสดงว่ารายการเสร็จสมบูรณ์ทั้งด้านเทคนิคและการทำงาน ระยะเวลาที่อยู่ในสถานะนี้อาจเป็นเวลารอคิวก่อนถึงช่วงเวลานำระบบขึ้นใช้งานตามกำหนด. แหล่งข้อมูล อนุมานจากการเปลี่ยนฟิลด์ 'State' เป็น 'Ready for Release' หรือติดตามเวลาที่ฟิลด์ 'Release' ในระเบียนรายการพัฒนาถูกกรอกหรืออัปเดต. บันทึก อนุมานจากการเปลี่ยนสถานะหรือการเชื่อมโยงกับระเบียน Release. ประเภทเหตุการณ์ inferred | |||
| บันทึกโค้ด | หมายถึงนักพัฒนาส่งโค้ดเข้า repository ของระบบควบคุมเวอร์ชันที่เชื่อมโยงกับรายการพัฒนา ServiceNow DevOps บันทึกเหตุการณ์นี้โดยตรงจากเครื่องมือ SCM ที่เชื่อมต่อ เช่น Git หรือ GitHub. | ||
| เหตุผลที่สำคัญ การติดตาม commit ช่วยให้เห็นความคืบหน้าและความถี่ของกิจกรรมพัฒนาอย่างละเอียด อีกทั้งยังช่วยเชื่อมโยงการเปลี่ยนแปลงโค้ดแต่ละครั้งกับรายการพัฒนาหลัก. แหล่งข้อมูล บันทึกเป็นเหตุการณ์โดยตรงในตาราง Commits [sn_devops_commit] ของ ServiceNow DevOps ซึ่งรับข้อมูลผ่าน webhook จากระบบจัดการซอร์สโค้ดที่เชื่อมต่อ. บันทึก บันทึกเมื่อได้รับ webhook แจ้ง commit จากเครื่องมือ SCM. ประเภทเหตุการณ์ explicit | |||
| พบงานที่ต้องแก้ไขซ้ำ | หมายถึงพบปัญหาระหว่างการทดสอบและต้องส่งรายการกลับไปให้ทีมพัฒนา อนุมานได้จากการย้อนกลับของขั้นตอน เช่น สถานะเปลี่ยนจาก 'In QA' กลับเป็น 'In Progress'. | ||
| เหตุผลที่สำคัญ การติดตามงานแก้ไขซ้ำจำเป็นต่อการทำความเข้าใจปัญหาด้านคุณภาพและจุดที่กระบวนการไม่มีประสิทธิภาพ หากพบกิจกรรมนี้บ่อย อาจชี้ถึงปัญหาในการพัฒนาหรือความชัดเจนของข้อกำหนด. แหล่งข้อมูล อนุมานจากการวิเคราะห์ประวัติฟิลด์ 'State' ในตาราง sys_audit หรือ sys_history_line การเปลี่ยนจากสถานะขั้นตอนหลัง เช่น 'Testing' กลับไปยังสถานะก่อนหน้า เช่น 'In Progress' หมายถึงมีงานแก้ไขซ้ำ. บันทึก อนุมานจากการเปลี่ยนสถานะย้อนกลับ เช่น 'Testing' -> 'In Progress'. ประเภทเหตุการณ์ inferred | |||
| ยกเลิกรายการพัฒนา | หมายถึงการยุติรายการพัฒนาก่อนเสร็จสิ้น เป็นสถานะสิ้นสุดอีกแบบหนึ่ง ซึ่งโดยทั่วไปอนุมานจากการตั้งสถานะของรายการเป็น 'Cancelled' หรือ 'Closed Incomplete'. | ||
| เหตุผลที่สำคัญ การติดตามการยกเลิกช่วยให้เห็นแรงงานที่สูญเปล่าและเข้าใจสาเหตุของการเปลี่ยนขอบเขตงานหรือการจัดลำดับความสำคัญใหม่ อีกทั้งยังช่วยให้เห็นผลลัพธ์ที่เป็นไปได้ของกระบวนการได้ครบถ้วนขึ้น. แหล่งข้อมูล อนุมานจากเวลาที่ฟิลด์ 'State' ในระเบียนรายการพัฒนาเปลี่ยนเป็นสถานะสิ้นสุดที่ยังไม่เสร็จสมบูรณ์ เช่น 'Cancelled'. บันทึก อนุมานจากการเปลี่ยนสถานะเป็น 'Cancelled' หรือสถานะสิ้นสุดที่มีความหมายเทียบเท่า. ประเภทเหตุการณ์ inferred | |||
| เริ่ม Build | เหตุการณ์นี้หมายถึงการเริ่ม build ของไปป์ไลน์ CI/CD ซึ่งมักเกิดจากการ commit โค้ด ServiceNow DevOps บันทึกเป็นการทำงานของไปป์ไลน์และเชื่อมโยงกลับไปยังรายการพัฒนาต้นทาง. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้เชื่อมขั้นตอนพัฒนาเข้ากับการทดสอบหรือการนำระบบขึ้นใช้งานโดยอัตโนมัติ การวิเคราะห์เวลาตั้งแต่ commit จนถึงเริ่ม build ช่วยให้เห็นความล่าช้าในกระบวนการ CI/CD. แหล่งข้อมูล บันทึกโดยตรงในตาราง Pipeline Execution [sn_devops_pipeline_execution] เมื่อเริ่ม build ในเครื่องมือ CI/CD ที่เชื่อมต่อ เช่น Jenkins หรือ Azure DevOps. บันทึก ดึงข้อมูลจากเวลาเริ่มต้นของระเบียนในตาราง Pipeline Execution. ประเภทเหตุการณ์ explicit | |||
| เริ่ม UAT | หมายถึงการเริ่ม User Acceptance Testing ซึ่งผู้มีส่วนเกี่ยวข้องทางธุรกิจจะตรวจสอบการทำงาน โดยอนุมานเหตุการณ์นี้จากการเปลี่ยนสถานะเป็น 'UAT', 'In UAT' หรือ 'User Acceptance Testing'. | ||
| เหตุผลที่สำคัญ ขั้นตอนนี้สำคัญต่อการตรวจสอบว่าฟีเจอร์ที่พัฒนาตรงตามความต้องการทางธุรกิจหรือไม่ การวิเคราะห์ระยะเวลาช่วยให้เห็นปัญหาการมีส่วนร่วมของผู้ใช้หรือความไม่ตรงกันของข้อกำหนด. แหล่งข้อมูล อนุมานจากการเปลี่ยนสถานะในระเบียนรายการพัฒนา โดยโมเดลสถานะของลูกค้าต้องมีสถานะ UAT แยกต่างหาก. บันทึก อนุมานจากการเปลี่ยนสถานะเป็น 'UAT'. ประเภทเหตุการณ์ inferred | |||
| เริ่มทดสอบ QA | หมายถึงการเริ่มขั้นตอนทดสอบอย่างเป็นทางการของ Quality Assurance โดยเกือบทุกกรณีอนุมานจากการเปลี่ยนสถานะของรายการพัฒนาเป็นค่าอย่าง 'In QA', 'Testing' หรือ 'Ready for Test'. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้บ่งบอกถึงการส่งต่องานจากทีมพัฒนาไปยังทีม QA ใช้วัดระยะเวลาการทดสอบและระบุคอขวดด้านกำลังการทดสอบ. แหล่งข้อมูล อนุมานจากเวลาที่ฟิลด์ 'State' ในระเบียนรายการพัฒนา เช่น Story หรือ Defect เปลี่ยนเป็นสถานะเฉพาะของ QA. บันทึก อ้างอิงเวลาที่สถานะเปลี่ยนเป็น 'Testing' หรือสถานะที่มีความหมายเทียบเท่า. ประเภทเหตุการณ์ inferred | |||
| เริ่มนำระบบขึ้นใช้งานจริง | กิจกรรมนี้หมายถึงการเริ่มไปป์ไลน์เพื่อนำระบบขึ้นสู่สภาพแวดล้อมใช้งานจริง ServiceNow DevOps บันทึกเหตุการณ์นี้โดยตรงเมื่อขั้นตอน production ของไปป์ไลน์ CI/CD เริ่มทำงาน. | ||
| เหตุผลที่สำคัญ นี่คือจุดเริ่มต้นของขั้นตอนสุดท้าย ซึ่งมักเป็นช่วงที่สำคัญที่สุดของวงจรการทำงาน การติดตามช่วยวิเคราะห์ระยะเวลาการนำระบบขึ้นใช้งานและหาโอกาสในการทำงานอัตโนมัติ. แหล่งข้อมูล บันทึกโดยตรงในตาราง Stage Execution Run [sn_devops_stage_execution] โดยกรองเฉพาะขั้นตอนที่เกี่ยวข้องกับสภาพแวดล้อมใช้งานจริง. บันทึก ดึงข้อมูลจากเวลาเริ่มต้นของขั้นตอนนำระบบขึ้นใช้งานจริงใน Pipeline Execution. ประเภทเหตุการณ์ explicit | |||
| เริ่มออกแบบ | หมายถึงช่วงที่กำลังจัดทำการออกแบบทางเทคนิคหรือสถาปัตยกรรมโซลูชันสำหรับรายการพัฒนา โดยทั่วไปอนุมานจากการเปลี่ยนค่าฟิลด์สถานะหรือ state ในระเบียนรายการพัฒนาเป็นค่าอย่าง 'Design' หรือ 'Solutioning'. | ||
| เหตุผลที่สำคัญ การวิเคราะห์ระยะเวลาของขั้นตอนออกแบบช่วยให้เห็นคอขวดในการแปลงความต้องการและวางแผนโซลูชัน ก่อนเริ่มงานพัฒนา. แหล่งข้อมูล อนุมานจากการเปลี่ยนสถานะในระเบียนรายการพัฒนา เช่น Story [rm_story] ให้ตรวจดูการเปลี่ยนค่าฟิลด์ 'State' หรือฟิลด์ 'Stage' ที่กำหนดเองเป็นค่าที่เกี่ยวข้องกับการออกแบบ. บันทึก อนุมานจากการเปลี่ยนสถานะเป็น 'Design' หรือสถานะที่มีความหมายใกล้เคียงกัน. ประเภทเหตุการณ์ inferred | |||
คู่มือการนำข้อมูลออก
ขั้นตอน
- ทำความเข้าใจโมเดลสถานะ: ก่อนสร้างรายงาน ให้บันทึกค่าที่ใช้ในฟิลด์สถานะของรายการพัฒนาของคุณ เช่น ในตาราง Story
[rm_story]หรือ Defect[rm_defect]ว่าค่าใดตรงกับกิจกรรมที่ต้องการ ตัวอย่างเช่น สถานะ 'In Progress' อาจจับคู่กับกิจกรรม 'Development Started' - ไปที่การสร้างรายงาน: เข้าสู่ระบบ ServiceNow instance ของคุณ ใน Filter navigator ไปที่
Reports > View / Runแล้วคลิกปุ่มCreate a report - สร้างรายงานสำหรับการเปลี่ยนสถานะ: สร้างรายงานแรกเพื่อเก็บกิจกรรมที่อิงตามสถานะ แล้วกำหนดค่าดังนี้
- ชื่อรายงาน:
ProcessMind - State Change Events - ประเภทแหล่งข้อมูล:
Table - ตาราง:
Audit [sys_audit] - ประเภท:
List - กำหนดคอลัมน์: เพิ่ม
Document key,Created on,Table name,Field name,Old valueและNew value - ตัวกรอง: ตั้ง
Table nameให้เป็นหนึ่งในตารางรายการพัฒนาของคุณ เช่นStoryและตั้งField nameเป็นฟิลด์สถานะ เช่นStateเพิ่มตัวกรองวันที่ในฟิลด์Created onตามช่วงเวลาที่ต้องการ
- ชื่อรายงาน:
- สร้างรายงานสำหรับการสร้างรายการ: สร้างรายงานใหม่เพื่อเก็บเหตุการณ์การสร้างรายการครั้งแรก
- ชื่อรายงาน:
ProcessMind - Item Creation Events - ประเภทแหล่งข้อมูล:
Table - ตาราง:
Story [rm_story]หรือใช้ตารางรายการพัฒนาหลักของคุณ - ประเภท:
List - กำหนดคอลัมน์: เพิ่มคอลัมน์ของแอตทริบิวต์ที่จำเป็น เช่น
Number,Created on,Assigned to,Priority,Stateเป็นต้น - ตัวกรอง: เพิ่มตัวกรองวันที่ในฟิลด์
Created on
- ชื่อรายงาน:
- สร้างรายงานสำหรับการ Commit โค้ด: สร้างรายงานสำหรับเหตุการณ์ DevOps ที่เกี่ยวข้องกับการ commit โดยตรง
- ชื่อรายงาน:
ProcessMind - Commit Events - ประเภทแหล่งข้อมูล:
Table - ตาราง:
Commit [sn_devops_commit] - ประเภท:
List - กำหนดคอลัมน์: เพิ่มคอลัมน์ เช่น
Work item,Commit time,Authorเป็นต้น - ตัวกรอง: เพิ่มตัวกรองวันที่ในฟิลด์
Commit time
- ชื่อรายงาน:
- สร้างรายงานสำหรับ Build และการนำไปใช้งาน: ทำตามขั้นตอนก่อนหน้าซ้ำสำหรับตาราง
Build [sn_devops_build]และDeployment [sn_devops_deployment]ตารางเหล่านี้มีระเบียนของกิจกรรมBuild Triggered,Deployment to Production Started,Deployed to ProductionและDeployment Failed - ส่งออกรายงานทั้งหมด: เรียกใช้รายงานแต่ละรายการแยกกัน ในแต่ละรายงาน ให้คลิกไอคอนเมนูบริบท (จุดสามจุดหรือลูกศรลง) แล้วเลือก
Export > CSVหรือExport > Excelจากนั้นบันทึกไฟล์ทั้งหมด - รวมและแปลงข้อมูล: เปิดไฟล์ที่ส่งออกด้วยโปรแกรมสเปรดชีตหรือเครื่องมือเตรียมข้อมูล รวมข้อมูลจากทุกไฟล์ด้วยตนเองไว้ในชีตเดียว สร้างคอลัมน์บันทึกเหตุการณ์ที่จำเป็น (
DevelopmentItem,ActivityName,EventTimeเป็นต้น) แล้วจับคู่ข้อมูลจากคอลัมน์ต้นทาง ตัวอย่างเช่น นำDocument keyจากรายงาน audit และNumberจากรายงาน Story มาใส่ในคอลัมน์DevelopmentItem - จับคู่ชื่อกิจกรรม: สร้างคอลัมน์
ActivityNameโดยแปลงข้อมูลต้นทาง สำหรับรายงานการเปลี่ยนสถานะ ให้ใช้โมเดลสถานะที่บันทึกไว้จับคู่ค่าNew valueกับชื่อกิจกรรม เช่น จับคู่สถานะ 'Testing' กับ 'QA Testing Started' สำหรับรายงานอื่น ให้กำหนดชื่อกิจกรรมเดียวกันให้แต่ละแถว เช่น กำหนดทุกแถวจากไฟล์ส่งออก commit เป็น 'Code Committed' - ตรวจสอบและบันทึกไฟล์: เพิ่มคอลัมน์
SourceSystemและLastDataUpdateพร้อมกำหนดค่าเดียวกันให้ทุกแถว ตรวจสอบว่าการประทับเวลาทั้งหมดใช้รูปแบบเดียวกัน บันทึกไฟล์รวมเป็น CSV ไฟล์เดียว ซึ่งพร้อมอัปโหลดไปยัง ProcessMind
การกำหนดค่า
- ตารางที่ต้องใช้: ตารางหลักที่ต้องใช้ดึงข้อมูล ได้แก่
Audit [sys_audit]สำหรับเหตุการณ์ที่อนุมานจากข้อมูล ตารางรายการพัฒนาที่คุณใช้ เช่นStory [rm_story],Defect [rm_defect]และตารางหลักของ ServiceNow DevOps ได้แก่Commit [sn_devops_commit],Build [sn_devops_build]และDeployment [sn_devops_deployment] - ตัวกรองสำคัญ: ตัวกรองที่สำคัญที่สุดคือช่วงวันที่ ซึ่งควรใช้ให้เหมือนกันในทุกรายงาน โดยอิงฟิลด์เวลา เช่น
Created on,Commit timeหรือStart timeสำหรับรายงานsys_auditต้องกรองTable nameเช่นrm_storyและField nameเช่นstateเพื่อให้ได้เฉพาะการเปลี่ยนสถานะที่เกี่ยวข้อง - ช่วงวันที่ที่แนะนำ: แนะนำให้ดึงข้อมูลย้อนหลัง 3 ถึง 6 เดือน เพื่อให้ได้ชุดข้อมูลที่เป็นตัวแทนโดยไม่กระทบประสิทธิภาพ หากเป็นระบบขนาดใหญ่ ให้แบ่งดึงข้อมูลเป็นรายเดือน
- กำหนดโมเดลสถานะ: คุณต้องเข้าใจโมเดลสถานะของรายการงานในองค์กรอย่างชัดเจน เพื่อจับคู่ค่าที่บันทึกในตาราง
sys_auditกับกิจกรรมทางธุรกิจ เช่น 'เริ่มทดสอบ QA' หรือ 'อนุมัติ UAT' ได้อย่างถูกต้อง - ข้อกำหนดเบื้องต้น: ผู้ดึงข้อมูลต้องมีบทบาท
report_userหรือสิทธิ์เทียบเท่าเพื่อสร้างและเรียกใช้รายงาน รวมถึงสิทธิ์อ่านตาราง DevOps และตารางพัฒนาแอปพลิเคชันที่กล่าวถึงข้างต้น ต้องติดตั้ง ServiceNow DevOps plugin และเชื่อมต่อกับเครื่องมือ SCM และ CI/CD ของคุณอยู่แล้ว.
ตัวอย่างคำค้น sql
/*
This extraction method uses the ServiceNow report builder UI. The following sections describe the configuration for each report that must be created and exported.
The exported data must then be manually combined and transformed into a single event log file.
*/
---
-- REPORT 1: Item Creation Events
---
Report_Name: ProcessMind - Item Creation Events
Source_Table: rm_story
Report_Type: List
Columns:
- Number (maps to DevelopmentItem)
- sys_created_on (maps to EventTime)
- 'Development Item Created' (create a formula or static column for ActivityName)
- Assigned to (maps to AssignedDeveloper)
- Priority (maps to DevelopmentItemPriority)
- State (maps to DevelopmentItemState)
- cmdb_ci (maps to ModuleComponentAffected)
- Type (maps to DevelopmentItemType)
- Assignment group (maps to AssignmentGroup)
Filters:
- sys_created_on ON Last 6 months
---
-- REPORT 2: Inferred State Change Events
---
Report_Name: ProcessMind - State Change Events
Source_Table: sys_audit
Report_Type: List
Columns:
- documentkey (maps to DevelopmentItem)
- sys_created_on (maps to EventTime)
- newvalue (maps to ActivityName, requires translation)
- user (maps to AssignedDeveloper)
ActivityName_Mapping_Logic (Example):
- WHEN newvalue IS '[Your Design State]' THEN 'Design Started'
- WHEN newvalue IS '[Your In Progress State]' THEN 'Development Started'
- WHEN newvalue IS '[Your QA State]' THEN 'QA Testing Started'
- WHEN oldvalue IS '[Your QA State]' AND newvalue IS '[Your In Progress State]' THEN 'Rework Identified'
- WHEN oldvalue IS '[Your QA State]' AND newvalue IS '[Your UAT State]' THEN 'QA Testing Completed'
- WHEN newvalue IS '[Your UAT State]' THEN 'UAT Started'
- WHEN newvalue IS '[Your UAT Approved State]' THEN 'UAT Approved'
- WHEN newvalue IS '[Your Release Ready State]' THEN 'Prepared For Release'
- WHEN newvalue IS '[Your Cancelled State]' THEN 'Development Item Cancelled'
Filters:
- tablename = 'rm_story'
- fieldname = 'state'
- sys_created_on ON Last 6 months
---
-- REPORT 3: Code Commit Events
---
Report_Name: ProcessMind - Commit Events
Source_Table: sn_devops_commit
Report_Type: List
Columns:
- work_item.number (maps to DevelopmentItem)
- commit_time (maps to EventTime)
- 'Code Committed' (create a formula or static column for ActivityName)
- author.name (maps to AssignedDeveloper)
Filters:
- commit_time ON Last 6 months
---
-- REPORT 4: Build Events
---
Report_Name: ProcessMind - Build Events
Source_Table: sn_devops_build
Report_Type: List
Columns:
- work_item.number (maps to DevelopmentItem)
- start_time (maps to EventTime)
- 'Build Triggered' (create a formula or static column for ActivityName)
Filters:
- start_time ON Last 6 months
---
-- REPORT 5: Deployment Events
---
Report_Name: ProcessMind - Deployment Events
Source_Table: sn_devops_deployment
Report_Type: List
Columns:
- work_item.number (maps to DevelopmentItem)
- start_time (maps to EventTime for 'Started' activities)
- end_time (maps to EventTime for 'Completed' or 'Failed' activities)
- state (maps to ActivityName, requires translation)
ActivityName_Mapping_Logic:
- WHEN state IS 'in_progress' THEN 'Deployment to Production Started'
- WHEN state IS 'successful' THEN 'Deployed to Production'
- WHEN state IS 'failed' THEN 'Deployment Failed'
Filters:
- start_time ON Last 6 months
- [Filter for production deployments based on your environment configuration]
---
-- Additional events like 'Code Review Performed' may require a separate report
-- on a table like `sn_devops_pull_request` if available and configured.
--- ขั้นตอน
- ข้อกำหนดเบื้องต้น: ตรวจสอบว่าคุณเชื่อมต่อเครือข่ายไปยัง ServiceNow ของคุณได้ และได้รับบัญชีบริการเฉพาะที่มีสิทธิ์อ่าน โดยบทบาท
itilและsn_devops.viewerเป็นจุดเริ่มต้นที่เหมาะสม บัญชีนี้ต้องเข้าถึงตารางอย่างrm_story,sys_auditและสคีมาsn_devops_* - ติดตั้ง ServiceNow ODBC Driver: ดาวน์โหลด ServiceNow ODBC driver ที่เหมาะกับระบบปฏิบัติการของคุณจากพอร์ทัลสนับสนุน ServiceNow แล้วทำตามคำแนะนำในการติดตั้ง
- กำหนดค่า DSN: ตั้งค่า System DSN (Data Source Name) ใหม่บนเครื่องที่จะใช้เรียกใช้ query ใน ODBC Data Source Administrator ให้เพิ่ม ServiceNow driver และกำหนด URL อินสแตนซ์ เช่น
yourinstance.service-now.comชื่อผู้ใช้ และรหัสผ่าน - เชื่อมต่อด้วย SQL Client: ใช้เครื่องมือ SQL client เช่น DBeaver, Microsoft SQL Server Management Studio (ผ่าน linked server) หรือภาษาสคริปต์อย่าง Python ที่มีไลบรารี ODBC เพื่อเชื่อมต่อ ServiceNow ด้วย DSN ที่ตั้งค่าไว้
- ระบุโมเดลสถานะ: ก่อนเรียกใช้ query คุณต้องระบุค่าที่องค์กรใช้จริงในฟิลด์
stateของตารางรายการพัฒนา เช่นrm_storyและrm_defectquery ตัวอย่างใช้ค่าทั่วไป เช่น 'In Progress' หรือ 'In QA' ซึ่งคุณต้องเปลี่ยนเป็นค่าที่ใช้อยู่จริง - ปรับ SQL Query: คัดลอก SQL query ที่ให้ไว้ไปยัง client แก้ placeholder ที่ต้น query รวมถึงวันที่เริ่มดึงข้อมูลและค่าสถานะที่ตรงกับกิจกรรมในวงจรการพัฒนาของคุณ
- เรียกใช้ Query: เรียกใช้ SQL query ทั้งหมดกับฐานข้อมูล ServiceNow ผ่านการเชื่อมต่อ ODBC การทำงานอาจใช้เวลานาน ขึ้นอยู่กับช่วงวันที่และปริมาณข้อมูล
- ตรวจสอบข้อมูล: เมื่อ query ทำงานเสร็จ ให้ตรวจสอบชุดข้อมูลที่ได้อย่างคร่าว ๆ ดูว่ามีกิจกรรมหลากหลาย และคอลัมน์สำคัญ เช่น
DevelopmentItem,ActivityNameและEventTimeมีข้อมูลตามที่คาดไว้ - ส่งออกเป็น CSV: ส่งออกผลลัพธ์ทั้งหมดเป็นไฟล์ CSV ตรวจสอบว่าไฟล์เข้ารหัส UTF-8 และชื่อหัวคอลัมน์ตรงกับชื่อคุณลักษณะที่ ProcessMind ต้องใช้ เช่น
DevelopmentItem,ActivityName,EventTime - เตรียมอัปโหลด: ตรวจสอบว่าไฟล์ CSV สุดท้ายไม่มีแถวว่างต่อท้าย และรูปแบบวันที่ของ
EventTimeและLastDataUpdateสอดคล้องกันและ ProcessMind รองรับ เช่นYYYY-MM-DD HH:MM:SS.
การกำหนดค่า
- ข้อกำหนดเบื้องต้น: ต้องเข้าถึงอินสแตนซ์ ServiceNow ที่เปิดใช้โมดูล DevOps และมีบัญชีผู้ใช้เฉพาะที่ได้รับสิทธิ์อ่านตารางที่จำเป็น ต้องติดตั้งและกำหนดค่า ServiceNow ODBC driver บนเครื่อง client
- การกำหนดค่า ODBC Driver: การเชื่อมต่อต้องใช้ URL อินสแตนซ์ ชื่อผู้ใช้ และรหัสผ่านหรือ OAuth token ควรทดสอบการเชื่อมต่อ DSN ก่อนเรียกใช้ query ที่ซับซ้อน
- กรองช่วงวันที่: query ที่ให้มามี placeholder
s.sys_created_on >= '2023-01-01'เพื่อจำกัดปริมาณข้อมูลที่ดึง แนะนำอย่างยิ่งให้กำหนดช่วงเวลา เช่น 6 ถึง 12 เดือนล่าสุด เพื่อให้ query ทำงานได้ภายในเวลาที่เหมาะสม - ปรับโมเดลสถานะ: ความแม่นยำของ query ในการอนุมานเหตุการณ์ขึ้นอยู่กับโมเดลสถานะทั้งหมด คุณต้องแทนค่าตัวอย่าง เช่น
[Your 'In Progress' State Value],[Your 'In QA' State Value]ด้วยค่าที่ใช้จริงในการตั้งค่า ServiceNow โดยค่าต้องตรงตามตัวพิมพ์เล็กและใหญ่ - ตารางรายการงาน: query นี้เขียนขึ้นสำหรับตาราง Story (
rm_story) หากองค์กรของคุณใช้ Defects (rm_defect), Enhancements (rm_enhancement) หรือประเภทงานอื่นด้วย คุณต้องเพิ่มตารางเหล่านั้นใน Common Table Expression (CTE) เริ่มต้นที่ชื่อDevItemsโดยใช้UNION ALL - ประสิทธิภาพ: การเรียก query โดยตรงกับอินสแตนซ์ ServiceNow ที่ใช้งานจริงอาจกระทบประสิทธิภาพ แนะนำให้ดึงข้อมูลปริมาณมากนอกช่วงเวลาที่มีการใช้งานสูง หากชุดข้อมูลมีขนาดใหญ่มาก ให้พิจารณาดึงข้อมูลแบบเพิ่มเฉพาะส่วน โดยอิงฟิลด์
sys_updated_on.
ตัวอย่างคำค้น sql
WITH DevItems AS (
-- This CTE selects the base set of development items to analyze.
-- Add other tables like rm_defect or rm_enhancement here using UNION ALL if needed.
SELECT
s.sys_id,
s.number,
s.sys_created_on,
s.sys_updated_on,
s.assigned_to,
s.priority,
s.state,
s.cmdb_ci, -- Module/Component Affected
s.sys_class_name, -- Development Item Type
s.assignment_group,
DATEDIFF(second, s.sys_created_on, s.closed_at) AS cycle_time_seconds
FROM rm_story s
WHERE s.sys_created_on >= '2023-01-01' -- *** Placeholder: Set your desired start date ***
),
StateChanges AS (
-- This CTE unnests the audit trail for state changes, which are used for inferred activities.
SELECT
a.documentkey AS item_sys_id,
a.sys_created_on AS change_time,
a.oldvalue,
a.newvalue,
-- *** Placeholder: Define the numeric order of your states to detect rework. Adjust values and names. ***
CASE a.oldvalue
WHEN '1' THEN 1 -- Open
WHEN '[Your 'Design' State Value]' THEN 2
WHEN '[Your 'In Progress' State Value]' THEN 3
WHEN '[Your 'In QA' State Value]' THEN 4
WHEN '[Your 'In UAT' State Value]' THEN 5
ELSE 0
END AS old_state_order,
CASE a.newvalue
WHEN '1' THEN 1 -- Open
WHEN '[Your 'Design' State Value]' THEN 2
WHEN '[Your 'In Progress' State Value]' THEN 3
WHEN '[Your 'In QA' State Value]' THEN 4
WHEN '[Your 'In UAT' State Value]' THEN 5
ELSE 0
END AS new_state_order
FROM sys_audit a
WHERE a.tablename = 'rm_story' AND a.fieldname = 'state'
)
-- 1. Development Item Created
SELECT
i.number AS DevelopmentItem,
'Development Item Created' AS ActivityName,
i.sys_created_on AS EventTime,
'ServiceNow DevOps' AS SourceSystem,
GETDATE() AS LastDataUpdate,
us.name AS AssignedDeveloper,
i.priority AS DevelopmentItemPriority,
i.state AS DevelopmentItemState,
ci.name AS ModuleComponentAffected,
i.sys_class_name AS DevelopmentItemType,
grp.name AS AssignmentGroup,
i.cycle_time_seconds AS DevelopmentItemCycleTime,
CAST(0 AS BIT) AS IsRework
FROM DevItems i
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id
LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id
LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
UNION ALL
-- 2. Design Started
SELECT i.number, 'Design Started', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.newvalue = '[Your ''Design'' State Value]' -- *** Placeholder: Adjust state value ***
UNION ALL
-- 3. Development Started
SELECT i.number, 'Development Started', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.newvalue = '[Your ''In Progress'' State Value]' AND sc.old_state_order < 3 -- *** Placeholder: Adjust state value and order ***
UNION ALL
-- 4. Code Committed
SELECT i.number, 'Code Committed', c.committed_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, i.state, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM sn_devops_commit c JOIN DevItems i ON c.work_item = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
UNION ALL
-- 5. Build Triggered
SELECT i.number, 'Build Triggered', b.start_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, i.state, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM sn_devops_build b JOIN sn_devops_commit_build cb ON b.sys_id = cb.build JOIN sn_devops_commit c ON cb.commit = c.sys_id JOIN DevItems i ON c.work_item = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
UNION ALL
-- 6. Code Review Performed
SELECT i.number, 'Code Review Performed', pr.closed_at, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, i.state, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM sn_devops_pull_request pr JOIN DevItems i ON pr.work_item = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE pr.state = 'merged' -- Or 'closed', depending on process
UNION ALL
-- 7. QA Testing Started
SELECT i.number, 'QA Testing Started', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.newvalue = '[Your ''In QA'' State Value]' -- *** Placeholder: Adjust state value ***
UNION ALL
-- 8. Rework Identified
SELECT i.number, 'Rework Identified', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(1 AS BIT)
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.new_state_order < sc.old_state_order AND sc.new_state_order > 1 -- Moved to an earlier state
UNION ALL
-- 9. QA Testing Completed
SELECT i.number, 'QA Testing Completed', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.oldvalue = '[Your ''In QA'' State Value]' AND sc.new_state_order > sc.old_state_order -- *** Placeholder: Adjust state value ***
UNION ALL
-- 10. UAT Started
SELECT i.number, 'UAT Started', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.newvalue = '[Your ''In UAT'' State Value]' -- *** Placeholder: Adjust state value ***
UNION ALL
-- 11. UAT Approved
SELECT i.number, 'UAT Approved', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.oldvalue = '[Your ''In UAT'' State Value]' AND sc.new_state_order > sc.old_state_order -- *** Placeholder: Adjust state value ***
UNION ALL
-- 12. Prepared For Release
SELECT i.number, 'Prepared For Release', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.newvalue = '[Your ''Ready for Release'' State Value]' -- *** Placeholder: Adjust state value ***
UNION ALL
-- 13. Deployment to Production Started
SELECT i.number, 'Deployment to Production Started', se.start_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, i.state, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM sn_devops_step_execution se JOIN sn_devops_artifact_build sab ON se.deployable = sab.sys_id JOIN sn_devops_commit_build cb ON sab.build = cb.build JOIN sn_devops_commit c ON cb.commit = c.sys_id JOIN DevItems i ON c.work_item = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE se.stage_name = 'Production' -- *** Placeholder: Adjust stage name ***
UNION ALL
-- 14. Deployed to Production
SELECT i.number, 'Deployed to Production', se.end_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, i.state, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM sn_devops_step_execution se JOIN sn_devops_artifact_build sab ON se.deployable = sab.sys_id JOIN sn_devops_commit_build cb ON sab.build = cb.build JOIN sn_devops_commit c ON cb.commit = c.sys_id JOIN DevItems i ON c.work_item = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE se.stage_name = 'Production' AND se.result = 'SUCCESS' -- *** Placeholder: Adjust stage name and result value ***
UNION ALL
-- 15. Deployment Failed
SELECT i.number, 'Deployment Failed', se.end_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, i.state, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM sn_devops_step_execution se JOIN sn_devops_artifact_build sab ON se.deployable = sab.sys_id JOIN sn_devops_commit_build cb ON sab.build = cb.build JOIN sn_devops_commit c ON cb.commit = c.sys_id JOIN DevItems i ON c.work_item = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE se.stage_name = 'Production' AND se.result = 'FAILURE' -- *** Placeholder: Adjust stage name and result value ***
UNION ALL
-- 16. Development Item Cancelled
SELECT i.number, 'Development Item Cancelled', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.newvalue = '[Your ''Cancelled'' State Value]'; -- *** Placeholder: Adjust state value *** พร้อมเริ่มต้นหรือยัง?
เริ่มปรับปรุงวงจรการพัฒนาซอฟต์แวร์ได้ตั้งแต่วันนี้ ใช้เทมเพลตข้อมูลนี้ค้นหาจุดที่ทำงานได้ไม่เต็มประสิทธิภาพและผลักดันการปรับปรุงอย่างต่อเนื่อง.
อย่ารอช้า เริ่มปรับปรุงวงจรการพัฒนาซอฟต์แวร์วันนี้
ระบุจุดที่ทำงานได้ไม่เต็มประสิทธิภาพ เพื่อลดระยะเวลาวงจร SDLC ลง 30% หรือมากกว่า.
ไม่ต้องใช้บัตรเครดิต เริ่มปรับปรุงได้วันนี้