ควรใช้ประวัติความเป็นมาในการถ่ายทอดข้อมูลที่สำคัญต่อนักพัฒนาหรือไม่?

ในระหว่างการประชุมเกี่ยวกับการย้อนกลับของ SDK ของบุคคลที่สามจากรุ่นล่าสุดมีการบันทึกไว้ว่านักพัฒนาของเราตั้งค่าสถานะไว้แล้วในประวัติการส่งมอบที่ไม่ควรใช้เวอร์ชันล่าสุด

นักพัฒนาบางคนแย้งว่านี่เป็นวิธีปฏิบัติที่ไม่ดีและควรมีการบันทึกไว้ในไฟล์ต้นฉบับ (เช่น// Don't upgrade SDK Version x.y.z, see ticket 1234) หรือในREADMEไฟล์ระดับโครงการแทน คนอื่นแย้งว่าเนื่องจากประวัติการกระทำเป็นส่วนหนึ่งของเอกสารโครงการจึงเป็นที่ยอมรับสำหรับข้อมูลดังกล่าวเนื่องจากเราทุกคนควรอ่านมันต่อไป

ควรใช้ประวัติการส่งข้อมูลเพื่อส่งข้อมูลสำคัญไปยังผู้พัฒนารายอื่นหรือควรทำซ้ำข้อมูลดังกล่าวไปยังตำแหน่งอื่นเช่นโครงการREADMEหรือความคิดเห็นในไฟล์ต้นฉบับที่เกี่ยวข้อง?

หากฉันจะดูการอัปเกรดเป็น SDK รุ่นที่ใหม่กว่าของบุคคลที่สามสถานที่สุดท้ายที่ฉันจะดูคือประวัติของระบบควบคุมแหล่งที่มา

หากผลิตภัณฑ์ของคุณใช้ SDK เวอร์ชัน 2.0 และมีคนสนใจอัพเกรดเป็น 3.0 ฉันไม่คิดว่ามันสมเหตุสมผลที่จะคิดว่าพวกเขาควรย้อนกลับไปในระบบควบคุมแหล่งที่มาของคุณย้อนหลังเพื่อดูว่าไม่ใช่ความคิดที่ดี

ที่นี่เรามีทีมวิกิที่มีหน้าข้อมูลที่น่าสนใจจำนวนหนึ่งซึ่งนักพัฒนาทุกคนอ่าน (อนุสัญญาการเข้ารหัสวิธีการตั้งค่าสภาพแวดล้อมการพัฒนาเพื่อสร้างผลิตภัณฑ์สิ่งที่บุคคลที่สามที่คุณต้องการติดตั้ง ฯลฯ ) นี่เป็นสถานที่ที่เหมาะสมสำหรับการเตือนไม่ให้อัพเกรดคลังของบุคคลที่สาม

มันควรจะถูกบันทึกไว้ในประวัติการกระทำ แต่สถานที่ที่ดีที่สุดที่จะนำการแจ้งเตือนอยู่ในที่เดียวกับที่คุณกำหนดการพึ่งพา หากคุณมีตัวอย่างไฟล์ maven .pom ที่ประกาศการพึ่งพาสิ่งประดิษฐ์ของคุณฉันจะทำสิ่งที่ชอบ:

<!-- Do not change the SDK version because it causes Foo crashes. For more detail see Issue #123 -->

เหนือ<dependency>เส้นของคุณโดยตรง

ปัญหา # 123 จะมีรายละเอียดเกี่ยวกับวิธีการขัดข้องรุ่นที่คุณอัปเดตเป็นสาเหตุของการขัดข้องและอาจจะเพิ่มไว้ใน Backlog ของคุณอีกครั้งเพื่อกลับมาใหม่ในภายหลัง - เป็นไปได้ว่าอาจมีเวอร์ชันใหม่กว่าอีกครั้ง ไม่ว่าจะโดยอัตโนมัติด้วยการแก้ไขตั๋วหรือด้วยตนเองคุณจะส่งอีเมลถึงทีมเพื่อแจ้งให้พวกเขาทราบเกี่ยวกับปัญหาปัจจุบันในขณะนี้และเมื่ออยู่ในตัวติดตามจะช่วยให้ผู้คนค้นพบมันอีกครั้งในภายหลัง

เหตุผลที่จะนำไปใช้กับการประกาศการพึ่งพาเป็นเพราะใครก็ตามที่ต้องการเปลี่ยนรุ่นจะเห็นได้ในขณะที่พวกเขาต้องการที่จะเปลี่ยนมันและเข้าใจว่าทำไมพวกเขาไม่ควร

ฉันจะไม่แสดงความคิดเห็นในซอร์สโค้ดเพราะฉันสามารถนึกภาพสถานการณ์ที่มีคนทำการตรวจสอบการอ้างอิงของคุณและเริ่มอัปเกรดได้ พวกเขาไม่จำเป็นต้องกลั้ว codebase สำหรับทุกความคิดเห็นของสิ่งที่ต้องทำเพื่อทำเช่นนั้น

การเชื่อมโยงไปยังตั๋วปัญหาช่วยให้นักพัฒนาที่อยากรู้อยากเห็นรู้ว่ามันล้มเหลวและอาจกลับมาอีกครั้งในภายหลัง หากปราศจากสิ่งนั้นมันอาจจะค่อนข้างคงที่และจะไม่ถูกปรับปรุงอีกครั้ง

ข้อมูลที่สำคัญและไม่เป็นสัญชาตญาณควรจัดทำเป็นเอกสารซึ่งผู้คนจะมองหาเมื่อพิจารณาข้อมูล

สำหรับทีมและโปรเจ็กต์ที่ฉันทำงานมาฉันจะส่งความคิดเห็นเกี่ยวกับสาเหตุที่เวอร์ชันใหม่ล้มเหลว ฉันจะเพิ่มเรื่องราวที่ค้างเพื่อลองอัปเกรดอีกครั้งหากเวอร์ชันใหม่ได้รับการแก้ไข ฉันจะเพิ่มความคิดเห็นในการสร้างระบบ / สร้างสคริปต์ที่เชื่อมโยงห้องสมุด

การย้อนกลับจะช่วยให้นักพัฒนาในอนาคตมีบริบทเมื่อมองเข้าไปในประวัติของโครงการ เรื่องราวที่ค้างทำให้ความต้องการการอัปเกรดนี้เป็นส่วนหนึ่งของโครงการ ความคิดเห็นของระบบบิลด์จะถูกต้องเมื่อการเปลี่ยนแปลงนั้นจำเป็นต้องมีเมื่อไลบรารีได้รับการอัพเดตในที่สุด

ฉันจะไม่แสดงความคิดเห็นในรหัสและฉันจะไม่เพิ่มลงใน README นักพัฒนาที่คิดเกี่ยวกับการลองอัปเกรดจะไม่มองที่ชิ้นส่วนเหล่านี้ หากคุณเพิ่มเข้าไปที่นั่นเมื่อแก้ไขปัญหากับไลบรารีแล้วและการอัพเกรดเสร็จสิ้นคุณจะต้องลบมันออก ขั้นตอนนี้มักจะถูกลืม: ส่งผลให้บันทึกย่อที่มีประสิทธิผลในการทำโครงการ

หากโครงการของคุณมีการตั้งค่าที่แตกต่างกันหรือการไหลที่แตกต่างกันคำตอบของคุณอาจแตกต่างกัน ฉันคิดว่ากุญแจสำคัญคือการใส่ข้อมูลให้ถูกต้องนักพัฒนาจะเห็นมันเมื่อทำงานเพื่ออัปเกรด ด้วยวิธีนี้หากเวลาไม่ถูกต้องสำหรับการอัปเกรดผู้พัฒนาจะเห็นและหยุดและเมื่อเวลานั้นถูกต้องนักพัฒนาจะเห็นและลบบันทึกเพื่อไม่ให้นักพัฒนาในอนาคตสับสน

ฉันต้องการให้ความเห็นของมัทธิวให้ความสนใจมากขึ้นโดยเน้นความคิดที่สำคัญของเขาในคำตอบ มีเหตุผลที่คุณไม่ต้องการอัปเกรด SDK ของคุณและเหตุผลนั้นควรถูกบันทึกไว้ในการทดสอบหน่วย ไม่ใช่การตรวจสอบหมายเลขการแก้ไข แต่เป็นเหตุผลที่แท้จริง

ตัวอย่างเช่นสมมติว่ามีข้อบกพร่องในเวอร์ชันใหม่ เขียนการทดสอบหน่วยที่ตรวจสอบข้อบกพร่องนั้น หากพวกเขาแก้ไขข้อผิดพลาดนั้นใน SDK ในภายหลังการอัพเกรดจะเกิดขึ้นอย่างราบรื่น หากมีการเปลี่ยนแปลง API ที่เข้ากันไม่ได้ให้เขียนการทดสอบที่ตรวจสอบว่ารหัสของคุณรองรับ API ใหม่หรือ SDK รองรับ API เก่า นั่นเป็นการทดสอบการรวมระบบมากกว่าการทดสอบหน่วย แต่ก็ควรจะทำได้

บริษัท ของฉันสร้างรายได้มากกว่า 50 สัญญาต่อวันและเราไม่ได้ใหญ่มากอย่างแน่นอน แม้ว่านักพัฒนาซอฟต์แวร์ทุกคนจะอ่านข้อความยืนยันทุกข้อความซึ่งตรงไปตรงมาพวกเขาก็ไม่ได้ทำด้วยเหตุผลทั้งหมดที่เราต้องการประวัติความมุ่งมั่นที่บันทึกไว้ก็เพราะผู้คนจำไม่ได้ และผู้คนจะไม่ย้อนกลับไปอ่านประวัติในภายหลังเว้นแต่จะมีปัญหา และพวกเขาก็ไม่มีเหตุผลที่จะสงสัยว่ามีปัญหาในการอัปเกรดที่เท่าที่พวกเขารู้ว่ายังไม่เกิดขึ้น

โดยทั้งหมดส่งอีเมลเพื่อป้องกันการซ้ำซ้อนในระยะเวลาอันใกล้และจดไว้ในสคริปต์การสร้างและ README หรือ errata อย่างไรก็ตามโดยเฉพาะอย่างยิ่งหากปัญหาเกี่ยวกับเวอร์ชันใหม่นั้นบอบบางและเสียเวลาในการแก้ไขปัญหาคุณจำเป็นต้องมีวิธีทำให้ชัดเจน นั่นหมายถึงการทดสอบหน่วย

ฉันถามคำถามใหม่ว่า "ฉันควรสื่อสารข้อมูลสำคัญที่ฉันค้นพบให้กับคนอื่น ๆ ในทีมผ่านการส่งข้อความหรือไม่?" เพราะฉันคิดว่านั่นทำให้เห็นได้ชัดว่าไม่คุณไม่ควร ฉันพยายามอย่างหนักในการสื่อสารมาก (นี่คือสิ่งที่ทีมพัฒนาส่วนใหญ่ต้องใช้ความพยายามอย่างแข็งขัน) และฉันทำทุกอย่างเท่าที่ทำได้เพื่อหลีกเลี่ยงการผิดพลาดหรือปล่อยให้พวกเขาโกหก

หากห่วงโซ่ของการกระทำที่นำฉันไปสู่การค้นพบดังกล่าวถูกกระตุ้นโดยตั๋วฉันจะอัปเดตตั๋ว (และตรวจสอบให้แน่ใจว่าคนที่ควรรู้เรื่องนี้มีทัศนวิสัย) ฉันอาจพูดถึงแบบตัวต่อตัว (หวัง อย่างน้อยก็ปล่อยให้ใครบางคนที่มีความรู้สึกจู้จี้บางอย่างที่ "Gee ฉันคิดว่า Damon พูดอะไรบางอย่างเกี่ยวกับการปรับปรุงที่") และแน่นอนฉันจะออกความคิดเห็นในรหัสที่จุดรวม SDK เพื่อให้ไม่มีใครสามารถปรับปรุง มันไม่มีโอกาสได้เห็น ฉันอาจดูว่าฉันสามารถติดมันที่ใดที่หนึ่งบน wiki dev ของเราได้เช่นกันแม้ว่าจะทำได้ดีกว่าด้วยการมองไปที่การจ้างงานในอนาคตไม่ใช่ทีมปัจจุบัน

ใช้เวลาเพียงไม่กี่นาทีเมื่อเทียบกับเวลาที่ใช้ในการเผชิญหน้าและค้นหาปัญหา แน่นอนฉันจะไม่ตัดสินใจว่าเอกสารของเราที่ใช้สัญญาณน้อยที่สุดและทิ้งไว้อย่างนั้น

มันควรจะอยู่ในประวัติการกระทำ แต่ไม่เพียง แต่จะต้องอยู่ในประวัติศาสตร์การกระทำจินตนาการในขณะที่คุณจ้างนักพัฒนาใหม่ คุณคาดหวังหรือไม่ว่าผู้พัฒนารายใหม่จะอ่านทุกข้อความที่ส่งมอบในช่วง 10 ปีที่ผ่านมาของโครงการของคุณเพราะสองคนนั้นมีความสำคัญต่อการทำความเข้าใจฐานรหัสของคุณหรือไม่

อันดับที่สองพูดถึงสถานการณ์ แต่ไม่ใช่การเปลี่ยนแปลงรหัสคุณจะทำ "เอกสาร" เพื่อให้คุณสามารถเพิ่มข้อความส่งข้อความตามบรรทัด "ส่งข้อความจากการแก้ไข 5432 ตอนนี้ไม่ถูกต้องนี่คือสถานการณ์ปัจจุบัน"

ฉันไม่แน่ใจว่าทีมงานของคุณสื่อสาร แต่ผมเชื่อว่าวิธีที่มีประสิทธิภาพมากที่สุดที่จะบอกว่านี้คือการเป็นครั้งแรกและส่งอีเมลไปยังกลุ่มอีเมลของทีมระบุว่าเป็น "ด่วน" กับร่างกายว่า

พวกเราไม่สามารถใช้ SDK v xyz ได้เพราะมันทำให้บัฟเฟอร์ Foo ล้นและบริการบาร์จะหยุดทำงาน ติดกับรุ่น xyy

นั่นคือสิ่งที่เราทำที่นี่และเป็นวิธีที่เชื่อถือได้มากที่สุดในการส่งข้อความออกไป หากคุณต้องการจุกจิกจริง ๆ (และถ้าระบบอีเมลของคุณอนุญาต) ขอ "การตอบรับการอ่าน" บนอีเมล

เมื่อคุณบอกทีมงานทั้งหมดแล้วเอกสารรายละเอียดเพิ่มเติมควรถูกนำไปใส่ไว้ในวิกิของทีม สิ่งนี้จะแตกต่างกันไปขึ้นอยู่กับโครงสร้างของเอกสารของคุณ หากคุณมีส่วนเฉพาะสำหรับแอปพลิเคชันของคุณการพึ่งพาและข้อกำหนดซึ่งจะเป็นจุดที่ดีในการเพิ่ม

สถานที่เพิ่มเติมเพื่อบันทึกปัญหาประเภทนี้อาจอยู่ในซอร์สโค้ดเองแม้ว่าอาจไม่ได้ผลเสมอไป หากSDK version ...มีการอ้างอิงในสถานที่ที่ชัดเจนเพียงแห่งเดียวหรือสองแห่งคุณสามารถรวมหมายเหตุเกี่ยวกับการไม่อัปเกรด

ประวัติไฟล์ในการควบคุมแหล่งข้อมูลอาจมีความยาวมากและขึ้นอยู่กับผู้พัฒนาอาจมีหลายรายการต่อวัน คนที่ออกไปพักผ่อนเป็นเวลาหนึ่งสัปดาห์อาจไม่มีเวลาอ่านประวัติความเป็นมาของสัปดาห์ ไฟล์ README เป็นสถานที่ที่ดีกว่าเนื่องจากเป็นจุดศูนย์กลางเล็ก ๆ น้อย ๆ และผู้คนอาจจะอยากอ่านมากกว่า แต่คุณไม่สามารถมั่นใจได้ว่าทุกคนจะอ่าน README ฉันคิดว่าพวกเขาอาจจะถ้าพวกเขาเห็นว่ามันเปลี่ยนไป ...

สิ่งนี้ควรได้รับการแสดงความคิดเห็น แต่จะได้รับประโยชน์จากการอยู่ในที่อื่นเช่นกัน

ใครก็ตามที่ตัดสินใจที่จะอัพเกรดจะต้องมีข้อเท็จจริง บุคคลนั้นอาจไม่ได้อยู่ในการควบคุมของแหล่งที่มา ถ้าใครจะอ่านเกี่ยวกับปัญหานี้ใน SO และไม่เคยใส่ลงไปในฐานรหัส?

ต้องมีเอกสารบางอย่างเกี่ยวกับ SDK ของบุคคลที่สามนี้

• มันแก้ปัญหาอะไรได้บ้าง?
• ทำไมจึงเลือกอันนี้
• ข้อควรพิจารณาเกี่ยวกับสิ่งที่ต้องทำ: เวอร์ชันอัปเกรดการทดสอบและอื่น ๆ
• ใครเป็นคนตัดสินใจเรื่องนี้

คุณมีกรณีที่บางสิ่งบางอย่างเช่นนี้เกิดขึ้นในการควบคุมเวอร์ชันและคุณควรแนะนำให้ทุกคนใช้ข้อมูลนี้ให้มากที่สุด มีเพียงทีมของคุณเท่านั้นที่สามารถตัดสินใจได้ว่ามีใครบางคนกำลังทำการค้นหาในเอกสารใด ๆ ตัวควบคุมแหล่งที่มาหรือตัวติดตามบั๊กเพื่อรับข้อมูลมากที่สุดเท่าที่จะเป็นไปได้ มิฉะนั้นคุณจะลืมใครบางคนจะทำมันต่อไปและคุณจะโชคดีถ้ามันเขย่าหน่วยความจำของใครบางคนและหมุนกลับได้อย่างรวดเร็วอีกครั้ง

ประวัติเป็นสถานที่ที่ดีในการใส่ข้อมูลที่มีไว้สำหรับผู้อ่านที่กำลังมองหามันอยู่และมีความรู้สึกโดยทั่วไปว่าควรจะอยู่ที่ไหน มันเป็นสถานที่ที่ดีมากในการใส่ข้อมูลซึ่งจะต้องนำเสนอให้กับผู้ใช้แทนที่จะค้นหา

ประวัติเป็นเนื้อหาขนาดใหญ่มากของข้อความที่ค่อนข้างไม่เรียงกัน พวกเขามักจะมีวัตถุประสงค์เพื่อให้ข้อมูลโดยละเอียดเกี่ยวกับสิ่งที่เปลี่ยนแปลงไปและนักพัฒนาซอฟต์แวร์ถึงเหตุผลที่มีการเปลี่ยนแปลง นี่อาจเป็นข้อมูลเกินกำลังจนกว่าจะมีใครรู้ว่ากำลังมองหาอะไร

หากผู้ใช้ไม่ทราบว่ากำลังมองหาอะไรข้อมูลนั้นจะถูกฝังอย่างรวดเร็วภายใต้บันทึกการกระทำหลายร้อยรายการและพวกเขาไม่มีเครื่องมือที่จะตัดกองข้อมูลที่อยู่ข้างหน้า

ฉันตีความสถานการณ์นี้ว่ามีปัญหาพื้นฐานสองประการอาจเป็นไปได้สามข้อ

• การอัปเกรด SDK ที่ไม่ต้องการทำให้เป็นที่มาซึ่งอาจส่งผลเสียต่อผลิตภัณฑ์
• จากคำถาม: ผู้มีส่วนร่วมที่ดำเนินการอัพเกรดที่ไม่ต้องการไม่ทราบเกี่ยวกับการตัดสินใจก่อนหน้านี้ที่เฉพาะเจาะจงที่จะไม่อัพเกรด

ในความคิดของฉันแรกของเหล่านี้เป็นร้ายแรงที่สุด หากการอัปเกรด SDK ที่ไม่พึงประสงค์สามารถทำให้เป็นรหัสดังนั้นปัญหาอื่น ๆ

มีคนแนะนำให้เพิ่มกรณีทดสอบหน่วยที่จะล้มเหลวหากตรวจพบการอัพเกรด แม้ว่าจะเป็นการป้องกันไม่ให้มีการอัปเกรดเกิดขึ้น แต่ฉันเชื่อว่านี่เป็นเส้นทางที่อันตรายซึ่งนำไปสู่การไหลของลาวาเมื่อเวลาผ่านไป ดูเหมือนจะหลีกเลี่ยงไม่ได้ที่ในบางจุดในอนาคต SDK จะได้รับการอัปเกรดเพื่อนำฟีเจอร์ใหม่หรือการแก้ไขข้อบกพร่องหรือเนื่องจากเวอร์ชันเก่าไม่ได้รับการสนับสนุนอีกต่อไป ลองนึกภาพการเกาหัวอาจจะเป็นข้อโต้แย้งที่จะเกิดขึ้นเมื่อการทดสอบหน่วยนั้นล้มเหลว

ฉันคิดว่าทางออกทั่วไปที่สุดคือการปรับกระบวนการพัฒนา สำหรับ git ใช้กระบวนการร้องขอการดึง สำหรับการโค่นล้มและเครื่องมือรุ่นเก่าให้ใช้กิ่งไม้และส่วนต่าง แต่มีกระบวนการบางอย่างที่ช่วยให้ผู้พัฒนาระดับสูงสามารถตรวจจับปัญหาเหล่านี้ได้ก่อนที่จะทำให้เป็นโค้ดเบสและส่งผลกระทบต่อผู้พัฒนารายอื่น

หากกระบวนการร้องขอการดึงถูกนำมาใช้ในสถานการณ์ของคุณและหากคำขอการดึงแต่ละครั้งแคบและเจาะจงจะไม่เสียเวลามากนัก คำขอดึงเพื่ออัปเกรด SDK จะถูกส่งไปและปฏิเสธพร้อมความคิดเห็นว่าไม่ต้องการอัปเกรด ไม่มีใครได้รับผลกระทบและไม่จำเป็นต้องเปลี่ยนการอัปเกรด SDK ในขณะนี้

แต่เพื่อตอบคำถามเดิมโดยตรงฉันเห็นด้วยกับผู้อื่นที่คาดหวังว่านักพัฒนาทั้งหมดจะอ่านประวัติการแก้ไขทั้งหมดของรหัสบันทึกประจำรุ่นและอื่น ๆ สำหรับการแจ้งเตือนเช่นนี้เป็นการเสียเวลาอันมีค่า เกิดอะไรขึ้นกับอีเมลสั้น ๆ ของทีม

ปัญหาที่สามที่เป็นไปได้: เหตุใดจึงไม่ต้องการการอัปเกรดตั้งแต่แรก เห็นได้ชัดว่านักพัฒนาอย่างน้อยหนึ่งคนคิดว่าการอัพเกรดจะเป็นเรื่องดี มีเหตุผลที่ดีมากมายในการชะลอการอัปเกรด แต่ก็มีเหตุผลที่ไม่ดีมากมาย ระวังเพื่อหลีกเลี่ยงการไหลของลาวา (รหัสที่เข้ากันได้แบบย้อนกลับโดยไม่จำเป็น) และลัทธิการขนส่งสินค้า ("เราไม่สามารถอัพเกรดได้ แต่ฉันไม่รู้ว่าทำไม") รูปแบบการต่อต้าน!

ฉันจะบอกว่าการเพิ่มข้อมูลประเภทนั้นลงในประวัติการกระทำนั้นก็โอเค แต่ก็ยังต้องมีการบันทึกไว้อย่างถูกต้อง เราเพิ่งเริ่มใช้การบรรจบกัน (โดย atlassian) สามารถค้นหาได้คุณสามารถตั้งค่าบางหน้าเป็นรายการโปรดและอื่น ๆ

เครื่องมืออื่น ๆ บางอย่างอาจเป็นสมุดบันทึกสาธารณะใน Evernote หรือ Google เอกสาร

เมื่อเพิ่มคำตอบของคาร์ลฉันจะใช้วิธีการที่บังคับใช้ข้อ จำกัด โดยอัตโนมัติซึ่งเป็นส่วนหนึ่งของกระบวนการเช็คอิน คุณต้องการบางสิ่งที่ไม่ต้องการการดำเนินการเชิงรุกใด ๆ ในนามของผู้พัฒนาเช่นการอ่าน doc / wiki / README และไม่สามารถแทนที่ได้อย่างซ่อนเร้น

ในพื้นที่ควบคุมแหล่ง TFS คุณสามารถกำหนดรหัสนโยบายการเช็คอินแบบกำหนดเองที่ดำเนินการกฎการเช็คอิน ตัวอย่างเช่นคุณสามารถกำหนดนโยบายที่ประเมินรุ่นในไฟล์กำหนดค่าด้วยการเช็คอินที่รอดำเนินการและจะล้มเหลวหากไม่เท่ากับ xyz กฎเหล่านี้จะป้องกันไม่ให้ผู้พัฒนาทำการตรวจสอบและสามารถให้ข้อความอธิบาย นโยบายสามารถแทนที่ได้ แต่เป็นไปได้ที่จะสร้างการแจ้งเตือนเมื่อเกิดเหตุการณ์เช่นนี้

ทางเลือกอาจเป็น gated-checkins ที่ล้มเหลวด้วยรูปแบบการทดสอบหน่วยที่ประเมินค่า SDK โดยตรงหรือโดยอ้อมตามที่ Karl กล่าว

ฉันขอขอบคุณคำตอบนี้เป็น TFS-centric มาก แต่อาจมีคุณสมบัติที่คล้ายกันในการควบคุมเวอร์ชัน / ระบบ CI ที่ใช้ในสถานการณ์ของคุณ (ถ้าไม่ใช่ TFS)